📘 Visual Builder — Wizard Guide

Audience: Control authors, compliance officers Time: ~10 min to build your first control with the Wizard

The Visual Builder (also called the Lego Builder or Wizard) lets you compose controls using a drag-and-configure interface. It generates Rego automatically. You can preview the generated Rego at any time and switch to the code editor if you need finer control.

🏗️ Build flow overview

1. Select resource + bouncer
2. Add conditions (principal / resource / action / context)
3. Group conditions with AND / OR logic
4. Choose effect (allow / deny / mask)
5. Configure context enrichment and post-decision actions
6. Preview Rego → Save → Deploy to Sandbox

📌 Step 1 — Select resource and bouncer

On the first page of the Wizard, select:

Resource — the protected asset this control applies to
Bouncer — which enforcement instance(s) will receive this control

This binding is important: the Policy Bridge syncs this control only to the linked Bouncer(s). A control not linked to a Bouncer will not enforce.

📌 Step 2 — Add conditions

Click Add Condition to add an attribute check. Each condition specifies:

Field	Example
Attribute	`user.department`, `action`, `resource.data_classification`
Operator	`equals`, `in`, `contains`, `starts_with`, `greater_than`, `regex`
Value	`"Finance"`, `["read","export"]`, `"CONFIDENTIAL"`

Full operator reference: equals · not_equals · contains · in · not_in · starts_with · ends_with · greater_than · less_than · regex

📌 Step 3 — Group conditions with AND / OR

Conditions can be grouped into logical blocks:

Group 1 (AND — all must be true):
  user.department  equals  "Finance"
  user.authenticated  equals  true

Group 2 (AND):
  action  in  ["read", "export"]
  resource.data_classification  equals  "CONFIDENTIAL"

Groups combined: AND (both groups must match)

Use OR between groups to express "match any of these scenarios":

Group 1 (user is Finance manager)  OR  Group 2 (user is auditor)

Troubleshooting: An attribute is not in the dropdown? The attribute comes from a connected PIP data source. Go to Settings → Data Sources, confirm the connection is active, and check the last sync timestamp.

📌 Step 4 — Choose the effect

Allow — permit the request when all conditions match
Deny — block the request when conditions match
Mask — allow but redact or transform sensitive fields in the response

📌 Step 5 — Configure context enrichment and post-decision actions

Context enrichment

Context enrichment pulls additional attributes into the decision at runtime from a connected PIP:

Click Add Context Source
Choose the Source type (PIP data source)
Select the Connection (the specific configured data source)
Map Attribute/Endpoint to a Target Path that your conditions can reference

Post-decision actions

Actions fire after the allow/deny decision. They don't change the outcome — they add operational side-effects:

Action type	Use case
`audit_log`	Append a structured decision record to Control Core audit trail
`notification`	Alert via Slack, Teams, PagerDuty, email
`webhook`	POST to an external endpoint (SIEM, ticketing, workflow)
`siem_log`	Write a structured event to Splunk, QRadar, or any SIEM
`approval_gate`	Pause request and require human approval before it proceeds
`break_glass_notify`	Notify on emergency override access

Configure each action:

Choose Action type
Choose Trigger: on_allow · on_deny · on_mask · on_error · always
Select Destination (a configured integration) via destination_ref
Select Credential reference via credential_ref

Best practice: Always add an audit_log action on every control. Start with audit_log + notification before enabling approval_gate to validate routing before hard-blocking requests.

Troubleshooting: Action did not fire?

Confirm BOUNCER_ENABLE_POST_DECISION_ACTIONS is not false in Bouncer config

Check trigger matches the decision outcome

docker compose logs bouncer | grep POST_DECISION_ACTION Full reference: Actions Reference

Rollout guidance for approval gates and break-glass

approval_gate and break_glass_notify can intentionally pause request flow. Do not enable hard gating before validating:

Start with audit_log + notification to confirm routing is correct
Test approval flows end-to-end in sandbox: submit a request → confirm approver receives notification → approve → confirm request proceeds
Enable approval_gate in a narrow scope (one endpoint, one user group) before expanding
Pending approvals surface in Controls → Approval Inbox and Settings → Approval Gates

🚀 Step 6 — Preview Rego and deploy

Click Preview Rego at any time to see the generated Rego policy code
If you need to tweak the logic, switch to Code Editor — the editor opens with the wizard-generated Rego pre-loaded
Click Save
Click Deploy to Sandbox → confirm the control status shows Active

🔒 Compliance starter packs

The Scenario Starter Catalog (in Controls → Templates) includes pre-configured packs for:

AI Security and Governance
Data Governance and Privacy
API Security and Partner Access
Financial and Payments Risk Controls
Healthcare and Clinical Access Controls
Identity, Workforce, and Zero Trust
DevSecOps, SDLC, and Release Governance
Third-Party and Vendor Access Governance
Insider Risk and SOC Automation

Each pack pre-fills conditions and action triggers for the scenario. Customise before deploying.

See the full list: Control Scenarios.

📌 Next steps

Control Scenarios — quickstart maps for all major scenarios
Actions Reference — full post-decision action reference with examples
Simulator & Testing — test your control before promoting to production
Rego Guidelines — if you want to understand or customise the generated Rego