Developers' Blog

Unleash the power of record access policies

post-thumb

Record access policies provide a powerful mechanism to control data access at a granular level. Whether you’re a developer or an administrator, understanding the value and capabilities of record access policies opens up a world of possibilities for designing sophisticated solutions. In this blog post, we will explore record access policies, why they are valuable, and the problems they help solve, and provide practical examples to showcase their application

What are record access policies?

Record access policies enable both administrators and developers to define rules for controlling the visibility of data (records) to users so you are able to isolate data to different groups of users, all based on the conditions you define.

Record access policies are composed of two elements.

Policies

A Policy is a group of related rules that can be enabled or disabled at the same time.

Rules

Rules are where the magic happens! The rule contains the logic that will allow or deny access to records. Specifically, a rule comprises of the following:

  • Object type: The name of the object you’d like the rule to apply to, for example, Jobs. it also accepts more dynamic configuration, for example, hasLookup:region, which means this rule will apply to any record of an object that has a lookup field named region. So if your policy is related to objects that are linked to a region, this will ensure that as you build out your data model over time, the rule will continue to apply and you won’t need to add specific rules for all applicable object types.

  • Filter: This is where you use the power of GraphQL and Elastic Query Language to define the records within the object that you’d like the rule to apply to. Let’s say your organization has a policy (see what I did there) whereby Account records should not be visible to scheduling teams when a customer becomes inactive. We can create a filter that will look for our custom field “Account status” and check if it’s set to “Active” or “Inactive”. In this case, we set the Filter to AccountStatus != ‘Inactive’.

  • Access Type: Define the rule to allow access to data or restrict it. As this is at the rule level, multiple rules within a single policy can have different access types for the same object type i.e. “Rule 1” might have an access type of Deny to lock down the data and “Rule 2” might have an access type of Allow to loosen the restrictions in certain cases.

  • Roles excluded: If you need to ensure that your rule(s) only apply to specific groups of users, you can simply exclude users with specific roles. A practical example of this might be where you don’t want the rules to apply to senior managers or those in the C-suite

  • Permission excluded: Similar to “roles excluded”, users can be excluded when their role(s) include specific permissions. That is, you want some policies to apply to everyone, but other policies don’t apply to people with certain functional permissions, for example:

    • Policy 1 - Everyone can only see data in their region.
    • Policy 2 - You can only see jobs in your region unless you have permission to dispatch jobs.

Unlock new possibilities

By now, you’re probably getting a few ideas on how you could leverage record access policies. Let’s explore some of the everyday use cases.

  • Regional data isolation Allow users to see only the data associated with their region(s).

  • Business unit data isolation Limit data access to users based on the team they work within (sometimes this can be region based; however, sometimes this can also be service based. Either way, you have the flexibility to achieve both).

  • Grant access to data Provide access to data when it meets certain criteria. For example, you might want to provide access to job records only if the user has been allocated to the job and the job status is not set to completed or canceled. This would result in the user being able to see their ‘active jobs’ only.

  • Improve user experience Removing ‘noise’ for your users reduces both the cognitive load users require to carry out their task and reduces unnecessary clicks (and you’d be surprised how fast that can impact productivity).

For example, if “Sally the scheduler” only manages the work schedule for the team in South San Francisco, we can filter out all data related to any other region. As a result, Sally doesn’t have to apply filters to list views or scroll through Accounts or Jobs that don’t relate to her day-to-day activity.

Get up and running fast with policy templates

Policy templates are a set of pre-configured policies and rules that solve for typical business use cases. For the launch of record access policies, there is a template for restricting data access by region. Over time, more templates will become available to accelerate the administration process. If there’s a particular template you’d like to see, let us know @SkeduloDevs on LinkedIn or Twitter!

With great power comes great responsibility

There’s no question that record access policies offer unprecedented control and flexibility. We’ve built it this way to solve some of the most sophisticated data access requirements. However, it’s essential to be mindful of the impacts of incorrectly configured and unoptimized rules. Without proper testing and validation, tenant performance and stability have the potential to be noticeably impacted.

Here are some tips on how you can ensure you are successful with record access policies from day 1:

  • Build and test your policies in a non-production environment.
  • Ensure your test plan includes integrations, extensions and customizations.
  • Ensure all subqueries in filters are essential; over-reliance on subqueries can directly impact performance.

APIs for developers

Explore all the APIs to create and manage record access policies in the Skedulo developer docs. They provide detailed documentation and examples to help you on your implementation journey!

Conclusion

Record access policies offer developers unprecedented control and flexibility over data access. By incorporating these policies into your solutions, you can design sophisticated data visibility and privacy rules. Get started today and let us know the solutions you build with this incredibly powerful feature.

References

comments powered by Disqus