Data policies

Roles decide what a person can do. Data policies decide what data a person can see. A data policy is a named, attribute-based rule that constrains which records an assignee can access - for example, "only conversations in the East region" or "only conversations handled by the viewer." Where roles gate actions and modules (see Roles & permissions), data policies filter the rows behind them.

Each policy is bound to one enforcing product. The list of fields you can build rules from comes from that product, so a Redflare policy queries Redflare data and a Discover policy queries Discover data.

You manage data policies per app, under Apps → (your app) → Manage → Data Policies. The list is scoped to that app's product.

Anatomy of a policy

Name and an optional description.
A slug - a short label generated from the name, which you can edit if you want a simpler or tidier one.
The enforcing product it targets.
A ruleset - the attribute conditions that define which records it grants.
A combine mode - whether the policy is permissive or mandatory (see How policies combine).

Policies are either System (seeded for you, read-only, shown with a lock badge) or Custom (fully editable). System policies can only be viewed; custom policies can be edited, duplicated, and deleted.

Creating a policy

From the Data Policies list, select New Policy to open the full-page editor.

Name and describe it. Edit the title and description inline at the top of the editor.
Choose how broad it is. Two switches sit above the rules:

Grant access to all records - when on, anyone assigned this policy can see every record, and the rule builder is hidden and ignored. This matches every record, i.e. grants access to everything.
Mandatory (always enforced) - controls how the policy combines with others, described in How policies combine.

Build the rules with the rule builder (below).
Save your policy.

The rule builder

The rule builder is a nested AND / OR tree. The top of each group is a combinator you can switch between:

Match ALL of the following (AND) - every condition must hold.
Match ANY of the following (OR) - any one condition admits the record.

Use Add condition to add a comparison, and Add group to nest a sub-group. You can nest groups a few levels for more complex logic.

Conditions: field, operator, value

Each condition compares a field to a value using an operator.

Field - chosen from the product's catalogue through a searchable picker, grouped by category (for Redflare these mirror its Conversation, Integration, and Metric groupings). Every field has a data type: string, number, date, enum, or boolean.
Operator - the picker only offers operators valid for the field's type:

| Operator | Applies to | Value | | --- | --- | --- | | equals / does not equal | all types | one value | | contains / does not contain | string | one value | | starts with / ends with | string | one value | | is greater than / is less than | number, date | one value | | is at least / is at most | number, date | one value | | is any of / is none of | all types | a list of values | | is between | number, date | a from-to range | | is empty / is not empty | all types | no value | | matches the viewer's attribute | all types | a user attribute |
Value - the input adapts to the operator: a single value, a list, a from-to range, or no input at all for is empty / is not empty.

The matches the viewer's attribute operator compares a field against an attribute of the person viewing the data, rather than a fixed value. It's how you write self-referential rules like "agent email equals the viewer's email" so each person only sees their own records - one policy that adapts per user.

If you change a condition's field to a different type, the operator and value reset so the condition can never be left in an invalid combination.

Ruleset summary

Below the builder, Stratforge One renders your rules as a plain-English sentence, for example: Show data where region equals "East" AND (channel equals "voice" OR channel equals "chat"). If a policy has no conditions at all, the summary warns that it grants access to all of your organization's data - a deliberate choice you should make through the Grant access to all records switch rather than by accident.

How policies combine

A user can have several data policies at once. The combine mode decides how they stack:

Permissive (the default, Mandatory switch off) - permissive policies are unioned: any one of them admitting a record is enough.
Mandatory (Mandatory switch on) - mandatory policies are AND-combined on top: they must always hold and narrow whatever the permissive policies grant.

The effective result is OR(permissive) AND AND(mandatory). Use permissive policies to grant access to slices of data, and mandatory policies to enforce a boundary that can never be widened.

Saving an already-assigned policy

If you edit a policy that's already assigned to people, Stratforge One shows an assignment impact summary first - how many users and groups the change will affect - so an edit is never applied silently. Confirm to apply, or cancel to keep editing.

Assigning a policy

A policy does nothing until it's assigned. You assign from the Assignments panel on the right of the policy editor, which has two tabs - Users and Groups - each showing a count and the current assignees.

Select Assign users or Assign groups.
Pick one or more targets from the multi-select picker (anyone already assigned is filtered out).
Confirm. To remove an assignment, select the × on its row.

You must save a new policy before you can assign it. In a brand-new, unsaved policy the Assignments panel is disabled with a reminder.

You can also assign policies from other places:

From a group - open a group under Directory → Groups, go to its Data Policies section, and either assign an existing policy or create a new one in a slide-over that immediately attaches it to the group. Every member of the group inherits the union of its policies.
From a user - open a user in Directory → Users to see policies directly assigned to them (which you can manage here) alongside policies inherited from their groups (read-only, badged with the source group).

Editing, duplicating, and deleting

From the Data Policies list, use the actions menu on any row:

System policies offer View only - they're read-only.
Custom policies offer Edit, Duplicate (creates a copy you can adapt), and Delete (with a confirmation, since it can't be undone).

The organization-wide default

What happens to someone who has no applicable data policy is set by an organization-wide default access mode, found under Apps → (your app) → Manage → Settings:

Permissive - a user with no applicable policy gets full access.
Restrictive - a user with no policy is denied all access until one is assigned.

This default applies across all products, so changing it asks you to confirm first.

Under a Restrictive default, people see nothing until you assign them a policy (directly or through a group). Under a Permissive default, a policy with no rules, or no policy at all, means full access. Decide your default before rolling policies out broadly.

Data policies

On this page