Scopes
About scopes and permissions for enablehr
To use or manage any resource in enablehr, you must use a token with the appropriate scope, and your user account must have appropriate permissions for that resource
For example:
To list employees in your account , your token must have the read:employees scope, and your user account must have read permissions for the account
These are the scopes currently available to the client.
| Scope | Description |
|---|---|
| read:accounts:referencedata | List and retrieve reference data of various field values. Eg: Genders, Honorifics etc. |
| manage:accounts:referencedata | Add, Update and Delete reference data of various fields. |
| read:employees | List all the employees in an account |
| manage:employees | Update employee data in an account |
| read:candidates | List all the candidates in an account |
| manage:candidates | Update employee data in an account |
| read:employees:payroll | List and retrieve Leave, payroll & tax data of employees (AU & NZ) |
| read:clear-tax-details | Retrieve unmasked TFN number for an employee in Australia |
| manage:employees:payroll | Update Leave, payroll & tax data of employees (AU & NZ) |
| read:accounts:training | List and retrieve training & qualifications setup data for an account |
| read:employees:training | List and retrieve training & qualifications data of employees |
| manage:employees:training | Update training & qualifications data of employees |
| read:users | List & retrieve enableHR and ESS users for an account |
Note: Your OAuth App can request the scopes in the initial redirection. You can specify multiple scopes by separating them with a space using %20:
Requested scopes and granted scopes
The scope attribute lists scopes attached to the token that were granted by the user. Normally, these scopes will be identical to what you requested. However, users can edit their scopes, effectively granting your application less access than you originally requested. You should be aware of this possibility and adjust your application's behavior accordingly.
It's important to handle error cases where a user chooses to grant you less access than you originally requested. For example, applications can warn or otherwise communicate with their users that they will see reduced functionality or be unable to perform some actions.
Also, applications can always send users back through the flow again to get additional permission, but don’t forget that users can always say no.
