Secure and Compliant Workflow App
Use Buzzy field security, viewer policies, Private Data, and audit trails to build secure review workflows.
Complexity: Advanced Time: 6-10 hours Purpose: Build an app that routes sensitive records through controlled review steps while limiting who can see and change each field.
Buzzy can support sophisticated workflows where different people see different parts of the same record. This is useful for legal review, compliance review, health record triage, employee case management, financial approvals, vendor onboarding, and other data-processing workflows.
The goal is not to make the app "compliant" by turning on one feature. The goal is to combine Buzzy controls so the app supports least privilege, data minimization, auditability, and controlled disclosure.
Pattern Overview
Use this pattern when a row moves through stages and each stage needs a different access profile.
Example roles:
Submitters create a record and see only their own safe fields.
Legal reviewers see contract, dispute, or regulatory fields.
Compliance reviewers see risk, evidence, and approval fields.
Managers see status and decision fields, but not every sensitive detail.
Admins configure the app and review audit evidence.
Example structure:
Who can open the app
App privacy and app roles
Who can see a row
Row Viewers and Team Viewers
Who can see a field
Field view
Who can change a field
Field edit
Who can see sensitive values
Private Data plus Field view
Who can reveal sensitive values
Sensitive Private Data reveal controls
What happened
Private Data audit trail
What integrations receive
REST API, MCP, and Async API server-side output shaping
Build the Workflow
1. Model the review groups
Create teams or organizations that match the real review boundaries.
Examples:
Legal Reviewers
Compliance Reviewers
Clinical Reviewers
HR Case Managers
Finance Approvers
Use teams when membership is managed inside a single organization. Use organizations when the app separates users by tenant, department, customer, region, or external partner.
2. Configure row-level access
Use row access to decide who can see the record at all.
For example, a case row might include:
the creator or submitter
the assigned reviewer
a Legal Reviewers team
a Compliance Reviewers team
a Team Viewers field that changes as the workflow stage changes
Row access is the first gate. A user must be allowed to see the row before field access or Private Data reveal is considered.
3. Configure field-level access
Use Field view and Field edit to make each stage least-privilege.
Use Workspace > Data > Fields to review the selected datatable's field policies in a grid. This helps you check that Legal, Compliance, Manager, and Submitter fields have the expected View, Edit, and Private Data settings before testing the workflow.
When a View or Edit option includes Viewers, select the relevant Viewer teams / organizations in the field editor. This is how a field becomes visible to a concrete group such as Legal Reviewers or Compliance Reviewers. The selected team or organization is still evaluated after row access, so it does not make the row visible by itself.
Example field policy:
Request summary
All participants
Creators & Viewers only
Legal notes
Admins, Authors, Creators & Viewers only, with Legal Reviewers selected
Same option, with Legal Reviewers selected
Compliance finding
Admins, Authors, Creators & Viewers only, with Compliance Reviewers selected
Same option, with Compliance Reviewers selected
Final approval
Admins, Authors, Creators & Viewers only, with Managers selected
Same option, with Managers selected
Internal audit notes
Admins, Authors, Creators & Viewers only, with Compliance Reviewers selected
Same option, with Compliance Reviewers selected
Field edit should never be broader than Field view. If a user cannot view a field, they should not be able to edit it.
For common policy meanings and examples, see Private Data field access settings.
4. Mark sensitive fields as Private Data
Use Basic Private Data for personal identifiers or contact details that should be minimized in normal output.
Use Sensitive Private Data for values that should be hidden by default and revealed only by authorized users.
Examples:
Customer email
Basic Private Data
Patient date of birth
Sensitive Private Data
Legal advice
Sensitive Private Data
Compliance evidence
Sensitive Private Data
Employee medical note
Sensitive Private Data
Uploaded identity document
Sensitive Private Data
Private Data applies to scalar fields and file/image fields. For denied users, file names, metadata, storage keys, and signed URLs are not exposed.
5. Keep safe workflow metadata separate
Private Data is intentionally not a good place for search, sort, or vector search.
Keep safe operational fields separate, such as:
status
priority
assigned reviewer
due date
region
risk category
review outcome
This lets builders create dashboards and queues without exposing sensitive raw values.
6. Use audit trail for evidence
Sensitive Private Data reveal attempts are audited. Admins can inspect reveal activity for a row from Workspace > Data:
Open the datatable row.
Expand Metadata.
Select Load audit trail.
The audit trail records who attempted access, which row and field were involved, the classification, purpose, time, and outcome. It does not store the revealed value.
Use this evidence for access reviews, incident investigations, and compliance checks.
7. Test every surface
Test as each user type:
runtime app screens
Workspace data view
REST API calls
MCP tools
Async API or Code Widget reads
exports and AI-generated contexts
The server should shape output before data leaves Buzzy. A denied user should see masked or hidden values, not raw values hidden only by client-side display logic.
Example Prompt
Related Topics
Last updated