Record access policies


Record access policies allow administrators to create filtering rules that get applied whenever data is requested via the web app, mobile app, or APIs. Record access policy rules filter the data that is returned for any given request.

Access record access policies

To view and manage record access policies, navigate to Settings > Data management > Record access policies.

This page lists any existing record access policies that you have in your Skedulo instance. Each policy listed also shows whether or not it is enabled.

From this page, you can perform the following actions:

  • Create a new policy.
  • Edit existing policies.
  • Delete policies.

Permission requirements

Only users with the Administrator role, or with a role containing the Modify record access policies permission, are allowed to create and manage record access policies.

Users with the Administrator role are automatically exempt from any record access policies and will always see all data from a Skedulo instance.

This gives administrators flexible fine-grained control over the data that each user can see based on a set of rules and conditions.

For example, you might want to enforce region isolation of your Skedulo data, where users should only see data records (such as Jobs, Accounts, Resources, etc) that belong to the region the user is associated with.

A record access policy can be configured that looks at the region associated with each job, account, resource, or other objects to be returned for a given request and filters out those with a region that is not associated with the current user.

A single policy consists of multiple filter rules. Once a policy has been created, multiple rules can be added to it, each with its own filter.

Types of record access

The normal value of Access Type is deny, which means data will only be returned if it passes the filter expression. When an object has a deny rule in effect, an allow rule can be added to override the deny rule if the given filter expression passes.

Another way to think of it is that deny filters are applied with the AND operator, while allow filters are added to any existing deny filters with the OR operator.

An allow rule on an object type that does not have a deny rule has no effect.

For example, you could have two rules on the Jobs object type:

  1. A rule that only returns jobs in the user’s region:
    "description": "Deny access to Jobs unless they are in a region associated with the user",
    "objectType": "Jobs",
    "filter": "RegionId IN (SELECT RegionId FROM UserRegions WHERE UserId == '{{userId}}')",
    "accessType": "deny",
    "permissionsExcluded": []
  1. An allow rule that also returns any jobs that have been allocated to the use (resource), regardless of regions:
    "description": "Allow access to Jobs that are allocated to the current Resource",
    "filter": "UID IN (SELECT JobId FROM JobAllocations WHERE ResourceId == '{{resourceId}}' AND Status != 'Deleted' AND Status != 'Declined')",
    "objectType": "Jobs",
    "accessType": "allow",
    "permissionsExcluded": []

See the API reference documentation for more information.