when configuring the underlying security of the platform, the use of permissions is heavily used it allows you to restrict visibility and access to records, fields and workflow transitions based on a combination of a user's role and condition of the permission note that if you want to restrict access to a table completely, permissions should be used, however if you want to hide a large amount of records based on a condition (not all), it is recommended that an table record restriction is used instead for performance reasons when you are configuring permissions, there are 3 different types of "protected types" each of these types have similar concepts, but have their own specific differences, as described below table permissions table permissions control access to the create, read, update, and delete table operations at the record level (e g you can control which users/roles can delete records in any table) example of a table permission table / tables table operations (obviously) apply to tables simple permissions that are based solely on role membership can be applied to multiple table (simply select multiple tables in the ‘tables’ field) advanced table permissions use logic that necessarily applied to a specific table (i e the condition builder and condition script) the table field will be toggled between a single and multiple select box if you select the ‘advanced’ option operation the operation defines the logical table operation that the permission is protecting this can be any combination of create applies when a record is attempting to be created read applies when a record is attempting to be read update applies when a record is attempting to be updated delete applies when a record is attempting to be deleted action the action defines which action the permission is enforcing this can be one of allow the permission/operation is allowed deny the permission/operation is denied order order controls the execution order of the permissions when multiple may apply to a particular table order is only used to order permissions of the same precedence the precedence and evaluation rules for the permissions will be outlined below admin overrides if the ‘admin overrides’ option is selected, the permission will not apply to anyone with the 'administrator' role roles this is a list of roles that the permissions will apply to you can select multiple roles negate roles if this option is selected, the roles will be negatively matched i e the permission will apply if the user does not have the specified role this option can be very useful for creating ‘deny’ permissions (e g deny delete access for anyone without the ‘administrator’ role) table permission evaluation table permissions are evaluated on a ‘first match wins’ basis rules are evaluated in a strict order, with the first matching rule (whether it is an allow or deny action) being used as the result this approach makes it very simple to reason about the execution logic, and it is easy to implement things like catch alls (i e at a very low precedence order), or explicit restrictions (i e at a very high order) permissions also inherit from table hierarchies, so rules for tables up the hierarchy will be applied if no more specific rule is found for the table itself permissions also support wildcard matching on the table, so catch all rules can be defined to apply to all tables (e g for administrators) if no permissions are matched , the default action is to deny access evaluation precedence the permission rules will always be executed with the following precedence rules type description precedence table all rules will be ordered by table first this means all rules for the current table will be evaluate, followed by each of the tables in the parent hierarch (in hierarchical order), followed by the wildcard table rules current table parent table hierarchy (if any) wildcard table order rules will then be sorted by the ‘order’ from the lowest order to the highest order in ascending values operation operations with the same precedence (i e same table/order) will be evaluated in the following order create, read, update, delete if multiple operations are specified, the ordering is more complicated, but will still be applied for example, with two rules of \[create, read, update] and \[delete], the first will still be higher precedence create read update delete action operations with the same precedence (i e same table/order/operation) will be evaluated with the deny rule first, followed by the allow rules deny allow id if we get to this level, the rules will be sorted by the permissions id, to ensure deterministic evaluation the id sorted alphanumerically field permission evaluation field permissions are evaluated in a almost exactly the same way as table permissions with one significant difference the default action for fields is the result of the table permission evaluation for that field (e g if the table read permission evaluation returns ‘allow’, the field read permission will return ‘allow’ if there are no more specific field permission matches similarly, it will return ‘deny’, if the table read permission evaluation returns ‘deny’ this difference is to ensure that the most common use case (to allow or deny access to an entire table) can be simply handled by just the table level rules typically, field permissions will only be required to restrict access to fields example field permission configuration transition permission evaluation in addition to field and table permissions, you can set the permissions for who can select any workflow transition option it is recommended if you want to restrict specific conditions, that you do it via the workflow transition condition instead, however, this will allow you to fully restrict the workflow options based on a condition (such as, allowing agents to change the workflow, but self service users not being able to unless allowed via a different method) reference fields for a reference field to be visible, you will need to have read permission for the reference field have read permission to the table that the reference field, references example is the out of box work table’s assignment group reference field the field will only display to you if you have read permission to the field and also if you have read permission to the group table that is referenced by the field table permission evaluation tool the permission evaluation tool allows testing of the permissions in a comprehensive and visual way the tool allows testing against roles or users (i e a users collection of roles), and against table and field level permissions the result shows all of the rules that were evaluated, and the result of the evaluation for each requested operation the permission evaluation tool, showing permission evaluation and precedence