> For the complete documentation index, see [llms.txt](https://docs.buzzy.buzz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/building-examples/secure-compliance-workflow.md). # Secure and Compliant Workflow App **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: | Control | Buzzy capability | | ------------------------------- | ------------------------------------------------------- | | 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: | Field | Field view | Field edit | | -------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------- | | 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](/the-building-blocks/datatables-fields-and-data/private-data.md#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: | Field | Private Data classification | | -------------------------- | --------------------------- | | 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**: 1. Open the datatable row. 2. Expand **Metadata**. 3. 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 ``` Create a compliance case review app. The app should let employees submit cases, then route cases to Legal Reviewers and Compliance Reviewers. Use teams for Legal Reviewers and Compliance Reviewers. Create a Case datatable with: - summary, status, priority, due date, assigned reviewer, and review outcome as non-private workflow fields - submitter email as Basic Private Data - legal notes, compliance findings, evidence summary, and uploaded evidence files as Sensitive Private Data Use row viewers and team viewers so only the submitter, assigned reviewers, and relevant review teams can open each case. Use Field view and Field edit so: - Legal Reviewers can view and edit legal notes - Compliance Reviewers can view and edit compliance findings and evidence summary - Managers can view final approval fields - Submitters cannot view internal legal or compliance notes Include screens for submitter case creation, reviewer queues, case detail, legal review, compliance review, manager approval, and admin audit review. ``` ## Related Topics * [Security and Access Control](/the-building-blocks/datatables-fields-and-data/security-and-access-control.md) * [Private Data](/the-building-blocks/datatables-fields-and-data/private-data.md) * [Building Compliance-Ready Apps](/the-ultimate-guide-for-vibe-coding-an-application-with-ai/best-practices/compliance-security.md) * [REST API microappdata](/rest-api/buzzy-rest-api/rest-api/microapp-data-operations/microappdata.md) * [MicroAppChild API](/rest-api/buzzy-rest-api/rest-api/microapp-data-operations/microappchild.md) * [Async API + React HTML Components](/the-building-blocks/code-widget-custom-code/new-async-api-+-react-html-components.md) * [MCP](/the-building-blocks/mcp.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/building-examples/secure-compliance-workflow.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.