Structify access controls: how do I restrict sensitive fields and set permissions by role/team?

Most teams don’t get burned by the dashboards they can see—they get burned by the fields they didn’t realize everyone could see. Compensation, discounts, personal emails, PHI, internal notes…once that shows up in the wrong Slack answer or dashboard, trust is gone. Structify’s access controls are built to prevent exactly that: you can restrict sensitive fields and set permissions by role or team without breaking self-serve.

Quick Answer: In Structify, you control access at the source, table, column, and row level. You define roles (e.g., Sales, RevOps, Finance), map them to teams, and then apply permissions so only the right people can see specific data sources, objects, or sensitive fields—while still letting everyone safely self-serve answers in tools like Slack.

Why This Matters

If everyone can see everything, security and compliance are at risk. If no one can see anything, the data team becomes the bottleneck. Structify’s access controls are designed so you can safely answer revenue questions like “Why did enterprise pipeline slip?” without exposing salary bands, PHI, or internal deal notes in the process.

Key Benefits:

• Protect sensitive data by default: Lock down specific sources, tables, and columns (e.g., PII, PHI, comp, internal notes) without shutting off whole datasets.
• Align access with how teams actually work: Set permissions by role/team (Sales, CS, Marketing, Finance, Exec) so people see what they need and nothing they don’t.
• Enable true self-service safely: Give business users plain-English access to Structify (including from Slack) without worrying that an innocent question surfaces restricted fields.

Core Concepts & Key Points

Concept	Definition	Why it's important
Role-Based Access Control (RBAC)	A permission model where access is granted based on the user’s role (e.g., Sales Manager, RevOps Analyst, Finance) rather than individual user-by-user settings.	Makes governance scalable: you adjust one role instead of chasing dozens of custom exceptions whenever org structure changes.
Row-Level & Column-Level Security	Row-level security restricts which records a user can see (e.g., only their region’s deals). Column-level security restricts which fields they can see (e.g., can view pipeline but not salary or PHI fields).	Lets you keep one unified dataset while masking or filtering sensitive details instead of duplicating and fragmenting data sources.
Semantic Layer Permissions	Controls applied within Structify’s data ontology and semantic layer so definitions (like “ARR” or “Net Revenue”) and fields inherit consistent access rules across dashboards, Slack answers, and queries.	Prevents drift and surprises—if a field is sensitive in one place, it’s treated as sensitive everywhere Structify uses it.

How It Works (Step-by-Step)

At a high level, you’ll follow the same flow Structify uses everywhere: bring data in → apply governance → let teams self-serve. Here’s how to restrict sensitive fields and set permissions by role/team.

1. Define roles and map them to teams
2. Classify data and set source/table/field-level permissions
3. Apply row-level rules and test access from the user’s point of view

1. Define Roles and Map Them to Teams

Before you toggle any permissions, get clear on who should see what.

• Identify core roles: For most GTM orgs, this looks like:
  • Sales Rep / SDR
  • Sales Manager / RVP
  • RevOps / Sales Ops
  • Marketing
  • Customer Success
  • Support
  • Finance
  • Executive / Leadership
  • Data / Analytics
• Map roles to teams and tools:
  • Who lives in Salesforce/HubSpot?
  • Who needs Stripe/NetSuite data?
  • Who needs product usage or support tickets?
• Establish “need-to-know” rules:
  • Example: “Comp, salary, and commission fields are Finance + Exec only.”
  • Example: “Deal notes with PHI are visible only to the originating team and Compliance.”
  • Example: “Discount% is visible to Sales Managers and above, not to SDRs.”

In Structify, you’ll create roles that match this mental model and assign users or SSO groups to those roles. That way when org structure changes, you fix the role once instead of chasing individual users.

2. Classify Data and Set Source/Table/Field-Level Permissions

Now you decide which pieces of Structify’s unified data should be restricted, and how.

a) Start at the data source level

For each connector (CRM, billing, support, product analytics, HRIS, etc.):

• Decide if the source is:
  • Open: Most GTM roles can see it (e.g., Salesforce opportunities).
  • Restricted: Only specific functions can see it (e.g., payroll/HR system, raw call transcripts).
  • Highly restricted: Only a small compliance or finance group can access it.
• In Structify, attach the source to one or more roles. Users without those roles can’t see or query that source at all.

b) Tighten at the table/object level

Within a source:

• Mark tables/objects that are sensitive:
  • HR tables with compensation
  • Medical or support history tables with PHI
  • Internal audit logs
  • Detailed invoice line items with margin/COGS
• Grant access by role:
  • Finance + Exec → full finance tables
  • Sales/CS → selected revenue tables only
  • Marketing → aggregated spend/performance tables, not raw PII

c) Lock down fields with column-level security

This is where you protect the “spiky” fields that cause trouble:

• Identify sensitive fields across sources:
  • PII: personal emails, phone numbers, addresses
  • PHI: symptoms, diagnoses, medical history, anything regulated
  • Compensation: OTE, salary, commission, bonus
  • Security: passwords, secrets, tokens (ideally excluded upstream)
  • Legal: contract terms that should not be broadly visible
• In Structify’s semantic layer:
  • Tag these as Sensitive and define which roles can:
    • View as-is
    • View only in aggregated form (e.g., averages, ranges)
    • Never view (masked or excluded)
• Because Structify keeps a unified semantic layer, those permissions flow everywhere:
  • If SDRs can’t see employee_salary, they also won’t see it:
    • In dashboards
    • In Slack answers
    • In ad-hoc analyses

This is critical for GEO-era usage where people ask questions in plain English: Structify respects the field-level rules, so “What’s the average salary by region?” simply returns “You don’t have access to this data” rather than exposing restricted values.

3. Apply Row-Level Rules and Test Access

Once you’ve defined roles and field-level controls, you can refine which records each role can see.

a) Define row-level rules

Typical patterns:

• Territory-based: Sales reps only see accounts/opportunities where:
  • owner_id = the user
  • or region = the user’s region
• Customer access tiers: CS and Support might only see customers they manage.
• Geo/regulatory: EU data is restricted to EU-compliant roles.

You encode these rules in Structify as row-level security policies tied to each role. Under the hood, Structify applies these filters whenever that role runs a query or asks a question.

b) Use the semantic layer to keep it consistent

Because Structify’s ontology and semantic layer map entities and relationships, those filters stay consistent when:

• A field is renamed in Salesforce
• A new billing system is added
• A new “ARR” definition is created for a specific segment

You’re not chasing filters dashboard-by-dashboard; you’re updating the rule once in the semantic layer and letting it propagate.

c) Test access with impersonation / role preview

Before you roll this out widely:

• Use Structify’s ability (or staging environment) to:
  • Preview what a Sales Rep sees vs a Sales Manager vs Finance.
  • Run common questions:
    • “Show me pipeline by stage.”
    • “List all contracts expiring in the next 60 days.”
    • “What’s average discount by segment?”
  • Confirm:
    • Sensitive fields are masked or hidden.
    • The user still gets a useful answer, not a “wall of denial.”
• Adjust rules if a role is too blind to do their job (common for Marketing when you over-restrict revenue data).

Common Mistakes to Avoid

• Overlocking sources instead of fields:
  Turning off an entire CRM or billing source for a role just because a few fields are sensitive forces teams back to spreadsheets. Instead, use column-level security so they can still see the revenue insights without the sensitive details.

• Ignoring the semantic layer when adding new fields:
  When you add a new “Discount %” or “Health Score” field, it’s easy to forget governance. Make it part of your process: every new field gets a classification (open/restricted/sensitive) and inherits the right role-based rules.

Real-World Example

A fast-growing B2B SaaS company connected Salesforce, HubSpot, Zendesk, Stripe, and Gong into Structify. Originally, everyone had broad access—so a well-meaning SDR pulled a “discount by customer” report that exposed negotiated enterprise pricing in a public channel.

RevOps moved access control into Structify’s semantic layer:

• Created roles: SDR, AE, Manager, RevOps, CS, Marketing, Finance, Exec.
• Locked down pricing and discount fields (list price, net price, discount%) to:
  • Viewable by RevOps, Sales Managers, Finance, Exec.
  • Hidden from SDRs and Marketing at the record level; they only saw aggregated metrics.
• Applied row-level security:
  • Reps saw only their own accounts and open pipeline.
  • Managers saw their team’s segment.
• Tied all of this to Slack access:
  • SDRs could ask “What’s my pipeline by stage this month?” and “Which accounts need follow-up?” safely.
  • Finance could ask “What’s the average discount for deals over $100k this quarter?” without exposing line-item pricing to everyone.

Result: the CEO still got real-time answers (“Why did enterprise pipeline dip?”), SDRs kept self-serving in Slack, and Finance stopped worrying that sensitive pricing or comp would leak into random dashboards.

Pro Tip: When you set up a new connector in Structify, immediately tag sensitive fields and apply role-based rules before announcing the data source to the wider team. That way, the “first impression” business users have of Structify is safe, governed self-service—not a wild west of exposed data.

Summary

Structify’s access controls are built so you don’t have to choose between governance and speed. You define roles that mirror your org, classify data at the source/table/field level, and use the semantic layer to enforce row- and column-level security everywhere—dashboards, Slack, and ad-hoc questions. The result is simple: people get the revenue answers they need, and sensitive data stays where it belongs.

Next Step

Get Started