Defining a custom permission

packages basic basic | | headcount planning headcount planning | compensation reviews compensation reviews | performance performance | engagement engagement | hris there are five elements that define a permission permission label this is the name of the permission, and it’s what you will see when selecting permissions in the roles screen 💡we recommend using a naming convention that starts with either allow or deny in accordance with what the permission is accomplishing for example a permission that allows a person to see the groups page in charthop might be labeled “allow read groups” permission description this is a full description of what the permission accomplishes 💡we recommend being as descriptive as possible, since this will help your team keep a better record of what each permission does, and helps ensure that any charthop administrators will give proper custom access to the often sensitive data stored in charthop without detailed descriptions, mistakes can happen allow/deny toggle this allows you to toggle whether the specific permission is to allow or deny access to data, pages, or actions in question ☝please note that you cannot combine both allow and deny into one permission using the permissions interface if you have a need to have both, you should instead create two separate permissions on the same role, or you can use the advanced editor entity and action drop downs there are two menus present in a permission that are linked together these choices are known as the permission’s entity action pair together, these define what the user is allowed to do (the action) on which part of the platform (the entity) first select the entity, or part of the platform you want to grant or deny access to then select the action, or what behavior you want to allow or deny for the given entity ☝please note that the action menu will change depending on the entity so please select an entity first common actions there are 4 basic actions that are present on most entities create create controls the ability to create instances of the entity for example, for an allow permission, if you select the entity group and the action create, then the permission would grant the ability to create new groups – new departments, teams and locations read read controls the ability to see that specific entity for example, for an allow permission, if you select the entity app and the action read, then the permission would grant the ability to see the list of apps that are available to be installed update update controls the ability to edit an already existing entity instance for example, for an allow permission, if you select the entity person and the action update , then the permission would grant the ability to edit or update the details of a person that is already created, such as updating someone’s legal name or work email delete delete controls the ability to delete a specific instance of an entity for example, for an allow permission, if you select the entity comp band and the action delete , then the permission would grant the ability to delete a comp band that is already created, like deleting an outdated band optional restrictions when defining a permission, you might want to restrict the scope of access we offer you three ways to restrict a permission’s scope field and category restrictions directions restrictions carrot (cql) filters we’ll dive into how to use each restriction type field and category restrictions field and category restrictions limit the permission to apply only to the specified fields or categories field and category restrictions can be used on person, job, business unit, and comp band entities some examples allow job\ read fields \[“basecomp”] grants the ability to see the “basecomp” field for all jobs in the system, but not other job fields allow job\ read categories \[“performance”] grants the ability to see all the fields in the “performance” category for all jobs in the system, but not other job fields deny person\ read fields \[“birthdate”] denies the ability to see the “birthdate” field for all people in the system keep in mind that every field in charthop applies to a particular entity, either person, job, business unit, or comp band depending on the specific field you would like to allow or deny access to, you will need to check the “applies to” option for that field on the fields list page, and select the appropriate entity when configuring your permission directions restrictions directions filters enable you to limit the permission according to the person’s position in the org chart direction filters can only be used with job and person entities there are four available directions self limits the permission to apply to the user’s own person or job under limits the permission to apply to those “below” the user in the org tree think the person’s direct reports, grand reports, all the way down the tree over limits the permission to apply to those “over” the user in the org tree think the user’s manager, grand manager, all the way up the tree peer limits the permission to apply to jobs outside of the person’s reporting line some examples allow job\ read directions \[“under, self”] grants the ability to see all the fields for the user’s own job and any jobs that report up into them deny person\ read fields \[“basecomp”] directions \[“over”] denies the ability to see the “basecomp” field for anyone over the user in the management chain (their manager, their manager’s manager, etc ) carrot filters in the event that you need to filter your permission by even more complex logic, you can use the generic carrot (cql) filter using a carrot filter on your permission will apply the permission only to jobs and people matching that filter string some examples allow job\ read filter ”job department=me department” grants the ability to see all the fields for any jobs whose department matches the user’s department (e g if the vp of engineering had this permission, she could see the job details of all jobs in the engineering department ) allow person\ read fields \[“address”] filter ”job location=’remote’” grants the ability to see address fields for any job with a “remote” location to learn more about how to use query expressions, check out our carrot docs