Record access policy templates
Record access policy templates are policies with a pre-configured set of rules that enforce data access controls for a specific use case. They are provided by Skedulo in the web app and allow administrators to quickly create a new policy for a common business requirement without having to manually create each rule. Basing a new policy off a template can help to ensure that the rules have adequate coverage and the correct structure, but extensive testing in a non-production environment is always required before new or updated policies are enabled.
NoteSkedulo may add more templates or edit existing ones over time as the overall product evolves. If a template changes in the future, any existing policies previously created from that template will not get those changes applied automatically.
Policy template: Data isolation by region
The Data isolation by region template can be used to create a policy that enforces isolation of your Skedulo data by region, where users can only see data records (such as Jobs, Resources, etc.) that belong to the region or regions with which they are associated. The policy looks at the region associated with each job, resource, and other objects to be returned for a given request and filters out those with a region that is not associated with the current user.
Use the Data isolation by region policy in your team
You can use the Data isolation by region policy by creating a policy from the template.
The Data isolation by region policy limits data access to users based on the region that is assigned to them. It requires that all users to whom the policy applies (all non-administrator users) are associated with one or more regions in their user record (see below for how to do this). If non-administrator users are not assigned to a region, they will not see any region-based data at all and will not be able to use the Skedulo web app.
A list of regions can be assigned to any user, regardless of their role. If a user is a resource, the Data isolation by region policy takes their primary and secondary regions into account. As a result, resources generally don’t need to have a region assigned to their user as well.
ImportantTake note when allocating or offering work to users in multiple regions. If a job or shift is allocated or offered to resources in multiple regions, then schedulers who can’t see all the relevant regions will only see the allocations or offers for resources in their own region(s). This may cause the work item to appear as though it has not been allocated or offered to anyone.
Associate users with regions
The ability to associate a user with a region is controlled by an admin setting in the web app. This configuration must be done before the User region field will appear in user records.
To enable the use of user regions, do the following:
- In Settings > General > Users, click to select Show the User regions field on user editing screens.
To associate a user with one or more regions, do the following:
- In Settings > Users, click the user to open the Users page.
- Click the User regions dropdown and select one or more regions to assign to the user.
- To save the changes, click Save. To leave the page without assigning regions, click Cancel.
For more information on how to edit users, see the documentation on user administration.
What is region-based data?
Skedulo allows for customization of the objects and fields in each team, so you will need to examine the data schema for your team to make sure that all object types that have a
Regions field or a lookup to
Regions is accounted for in your testing.
Can secondary regions be used to give temporary visibility of resources to schedulers in other regions?
If a resource has a primary region that the scheduler cannot see, but a secondary region that they can, then the scheduler user will not be able to see the resource. This is because the rule looks up the primary region of the resource first, and blocks visibility based on that region.
There may be a requirement to assign a secondary region to a resource so that they are visible to schedulers in that region. For example, a resource’s primary region is New York and a scheduler’s user region is Philadelphia. If the resource is going to help out in Philadelphia for a while, then the scheduler needs to allocate jobs to them there.
A workaround is to give the scheduler full access to New York or to change the resource’s primary region for the duration of the work in Philadelphia.
Was this page helpful?