Common Rule Scenarios

In this guide, you'll create rules for common situations that might arise in your organization.

Hide data from everyone

When no client should see a data class unless a more specific rule says otherwise, use this rule.

For example, you might want to hide personally-identifiable information (PII) from everyone.

Before you create the rule, tag the personal data fields with sensitivity:PII.

Set the rule like this:

Hidden removes the field from the response with no indication the field exists. When the client should learn that a rule has blocked the field, select Error instead. The response then returns an error that says the field is blocked by a rule. When the client should be able to ask for the data, use Let clients request denied data.

Let one group see hidden data

When one team should receive data that a Denied rule for Everyone on a tag blocks, use this rule. The group rule uses the same tag. The group rule overrides the Everyone rule for that actor.

Before you create the rule, tag the personal data fields this group should see with sensitivity:PII.

Set the rule like this:

Allowed returns the field as-is. Everyone outside that group still matches the deny rule.

Let clients request denied data

When a client should be blocked and should be able to ask for access, use this rule. To grant or decline the request, you need an Org Admin role.

For example, you might want to deny mutations (fields that edit data or take actions) but still allow someone to submit an access request for that mutation.

Before you create the rule, tag the fields that require approval with require-approval.

Set the rule like this:

Can Request blocks the field and tells the client that access can be requested. The request appears on Access requests. Approve or decline the request in Manage Access Requests. A Hidden denial removes the field without saying the field exists, so a Hidden denial never produces a request.

Hide data from one group

When one team should not see a data class, and every other actor should, use this rule.

For example, you might want to hide billing data from contractors.

Before you create the rule, tag the billing fields with sensitivity:financial.

Set the rule like this:

Actors outside that group are unaffected.

Redact a value

When the client needs the field in the response and must not receive the stored value, use this rule.

For example, you might want to redact compensation shown to a broad group.

Before you create the rule, tag the compensation fields with sensitivity:financial.

Set the rule like this:

The client receives the field with the value redacted. Add an Allowed rule on the same tag for the group that should see the stored value, as in Let one group see hidden data.

Restrict one client

When one client must not see data that other clients can see, use this rule. The client must already appear on Clients. An interactive session appears after that person connects. Register an agent app before you can select the app. For more information, go to Choose the client.

Before you create the rule, tag the personal data fields with sensitivity:PII.

Set the rule like this:

Only that client is affected. A specific-client rule overrides an All clients rule for that client.

Hide a whole service

When every field on one service should share one effect, use this rule. This pattern targets the service, so you don't tag the service's fields first.

Set the rule like this: