Setting Up Data Access Policies

Data access policies control what data each person on your team can see through Pingd. This is critical for sales organizations where reps should only see their own accounts, while managers see their team's data.

How the Policy Engine Works

Think of policies as filters. When a rep asks Pingd a question, the policy engine checks:

1. Who is asking? — Their email, role, and organization
2. What are they asking about? — Which tables and fields
3. What policies apply? — Rules matched by priority (user-specific → role-based → org-wide)
4. Return filtered results — The rep only sees what they're allowed to

This all happens automatically in real-time. Reps don't see policy mechanics — they just get the right data.

Policy Priority

Policies are evaluated in a strict priority order. The most specific match wins:

1. User-specific policies — Rules targeting a specific user by email or ID. Highest priority.
2. Role-based policies — Rules targeting a role (e.g., member, admin). Applied if no user-specific policy exists.
3. Org-wide defaults — Catch-all rules for the entire organization. Lowest priority.

This means you can set a broad org-wide policy ("reps see own accounts only") and then override it for specific users or roles as needed.

Creating Policies

Navigate to Settings → Data Access → Policies in the admin dashboard and click Create Policy.

Policy Components

Each policy has three layers of control:

Table-Level Access

Control which data tables a user or role can query:

• Allowed tables — Whitelist of tables the policy grants access to (e.g., accounts, contacts, opportunities)
• Denied tables — Blacklist of tables explicitly blocked (overrides allowed)

If no table restrictions are set, all tables are accessible by default.

Row-Level Filters

The most powerful feature. Row filters restrict which records within a table are visible. Filters are defined as conditions that get injected into every query's WHERE clause automatically. Example: "Reps see only accounts they own"

{
  "accounts": [
    {
      "column": "user_access",
      "operator": "eq",
      "value": "{{user_email}}"
    }
  ]
}

This adds WHERE user_access = 'rep@company.com' to every accounts query for that rep.

Field-Level Access

Restrict which columns are visible per table:

• Allowed fields — Whitelist of columns returned in query results

If no field restrictions are set, all columns are returned.

Template Variables

Row filters support dynamic template variables that resolve at query time:

Variable	Resolves To	Example Use
{{user_email}}	The querying user's email address	Filter records by owner email
{{user_id}}	The querying user's internal ID	Filter records by owner ID
{{org_id}}	The user's organization ID	Scope data to the org

Example: A single policy using {{user_email}} works for every rep — each sees only their own records without needing individual policies.

Cross-Connector Column Mapping

Different data sources use different column names for the same concept. For example, a Snowflake database might use OWNER_EMAIL while Salesforce uses Owner.Email. The column_mappings system on each table translates between your policy's column names and the actual column names in each connector.

This means you write policies once using logical column names (like user_access), and the mapping layer translates them to the right physical column for each data source. Column mappings are configured per table in Settings → Connections → Table Settings.

External Connector Scoping

Policies apply uniformly across all connector types. Whether your data lives in Snowflake, S3, Salesforce, Redshift, or PostgreSQL, the same policy rules are enforced. The policy engine evaluates access before the query reaches the connector, so there's no way to bypass filters by switching data sources.

Each policy is scoped to an organization, and each org's primary connection determines where queries go. The policy engine doesn't care which connector type is behind it — it adds the same filters regardless.

Common Policy Configurations

Small Team (< 10 reps)

• Members: See own accounts + deals (row filter on {{user_email}})
• Admins: See all accounts + deals
• Owner: Full access

Mid-Market Team

• SDRs (member role): See assigned leads and contacts only
• AEs (member role, user-specific): See assigned accounts, all contacts at those accounts, own deals
• Managers (admin role): See their team's accounts and deals
• VP/Director (owner role): Full access

Enterprise Team

• Named Account Reps: User-specific policy scoped to their named accounts
• Managers: Role-based policy for team + territory data
• Executives: Org-wide full access

Policy Caching

For performance, evaluated policies are cached for 60 seconds per organization. When you save a policy change in the admin dashboard, the cache is automatically cleared so changes take effect immediately.

Audit Trail

All policy changes are logged:

• Who changed the policy
• What was changed
• When it was changed

View the audit log at Settings → Data Access → Audit Log.

Pro Tip: Start with broad role-based policies using {{user_email}} filters, then add user-specific exceptions as needed. It's easier to start restrictive and open up than the reverse.

See also: Custom Data Definitions · Managing Users & Roles · Security & Compliance