Block access determines who can see the block against which object Ids.
It controls who can see the block. It does not control what you see in the block. The "what" is defined by security on the data provider and this varies by block type.
You can set up multiple access policies for each block. An access policy might:
- Grant anonymous access for public blocks (such as on a careers site or Intranet portal)
- Grant all authenticated (logged in) user's access to a subset of object Ids (for example, blocks against your own user Id)
- Grant a named role access to a subset of object Ids (for example, employees accessing blocks for their own person Id; managers accessing block for their direct reports' personIds)
- Grant elevated access to super users (for example, HRBPs accessing blocks against any object Ids)
If a user satisfies multiple access policies, they will be awarded combined access across all the satisfied policies.
When defining an access policy grant you specify two parts:
- The grantee that the policy applies to. See Available grantees.
- The object Ids the grantee can access. See Accessible object Ids.
Available grantees
When creating a grant to view a block you specify the role of who should have access to see the block. You can choose between the following roles:
- Anonymous (GUEST)
- All authenticated users (any logged in user)
- Named role (eg, Employee, Manager, HRBP)
Accessible object Ids
You can also specify which object Ids are accessible. These can be one of:
- All rows (the grantee can access this block against any object Id)
- A subset of object Ids (the grantee can access this block for a subset of object Id)
If the block does not specify an object, the accessible Object Ids are not available when creating access policy grants.
An absence example
The following table gives example policies against two blocks on an absence page:
| Page | Block | Role | Object Ids |
|---|---|---|---|
| leave-and-absences/123 | Absence listing | Employee | For own PERSON_ID |
| leave-and-absences/123 | Absence listing | Manager | For direct report PERSON_IDs |
| leave-and-absences/123 | Policy notes | Employee | For own PERSON_ID |
In this example, if the logged-on person was person Id 123 and they viewed leave-and-absences/123 they would see both the Absence listing and Policy notes blocks. If the logged-on person Id was 456 and this person was 123's manager, he or she would also see this page but only the Absence listing block; they wouldn't see the Policy notes block because although a manager is likely to have the Employee role the Policy notes grant only gives access to your own PERSON_ID.
If the logged-on person Id was 789 and this person was unrelated to person 123 they wouldn't see this page because they have access to none of the blocks. They would, however, be able to see leave-and-absences/789.
Block object
Most blocks are linked to an Object. The object is the basis for block access control.
Each object defines up to 5 primary keys. Your choice of object is important: you must choose an object with primary keys that have matching names to keys set by the owning page (see Pages). Here's an example of how to block access is determined for an absence page:
- A user attempts to access the page leave-and-absences/123
- The object Id format for the page is {PERSON_ID} so the page automatically creates the key PERSON=123. It also creates the keys ASSIGNMENT_ID=456 and USER_ID=789 because the page specifies an object Id handler
- The block is based on the object Applaud HR Assignment, which specifies primary key 1 as ASSIGNMENT_ID
- Access control restricts the block using a PAGE.ASSIGNMENT_ID = BLOCK.ASSIGNMENT_id join
- The object Id restrictions are applied to determine whether ASSIGNMENT_ID 456 is accessible or not
Creating access policies grants
To create an access policy for a block:
- Navigate to the block
- Go to the Grants section and press Add
- Specify the Grantee and the Object Id restriction