Skip to main content
Project settings govern how the project behaves, who can release it, how PHI is handled, and how integrations are configured. Settings are accessible from the project overview or from the Settings section of the resource tree.

​
Named configuration values

Settings (the resource type) are named values referenced by name in workflow contracts: 
compliance_officer_email    → [email protected]
urgent_routing_recipients   → ["[email protected]", "[email protected]"]
practice_timezone           → America/Chicago
Workflows reference settings by name: “send the alert to urgent_routing_recipients.” Change the setting value once; it propagates to every workflow that references it without re-authoring.

​
Creating a setting

In chat: “Add a setting for the compliance officer’s email address.” Or from the Settings resource section, click New Setting and supply a key and initial value. Settings changes are draft changes that become part of the next release. A setting change that affects a live workflow does not take effect until the project is released.

​
Release policy

Release policy controls the approval gate for this project.
SettingDescription
Required approversHow many approvals are required before a release can publish. 0 = direct publish. Must be ≥ the org floor.
Approver poolWho can approve releases. Default: any project member with the release-approval permission.
To change the required approvers, go to Settings → Release Policy and set the count. The change takes effect on the next release request.
The org sets a floor for all projects. You can set your project higher than the org floor but not lower. If your org requires 1 approver for all projects, you cannot set this project to 0.
For compliance-sensitive projects (e.g., any project that processes PHI), consider requiring at least 1 approver to enforce separation of duties on every release.

​
PHI policy

PHI policy governs how protected health information is handled within this project.
SettingDescription
PHI detectionWhether inbound payloads (form submissions, webhook payloads, integration events) are scanned for PHI before processing
PHI redaction in tracesWhether PHI is redacted in trace view for members without explicit PHI-view access
PHI in sandboxWhether synthesized PHI is permitted in sandbox test inputs
AI inference PHI guardWhether all AI inference steps in this project run under the PHI guard (detect → anonymize → infer → re-identify)
For healthcare orgs under a signed BAA, the default PHI policy is strict: detection enabled, redaction enabled, AI guard enabled. For non-PHI projects, you can relax these settings to reduce processing overhead.
Relaxing PHI policy on a project that processes real patient data is a compliance risk. Consult your compliance officer before changing PHI policy settings for any project under a BAA.

​
Integration configuration

The integration credentials configured in this project are managed from Settings → Integrations. For each integration:
  • View the connection status (connected, expired, error)
  • Rotate credentials without changing the integration’s reference in workflow contracts
  • Test the connection (fires a test call in sandbox mode)
  • Remove the integration (blocked if any workflow depends on it)
Credentials are stored encrypted and are never exposed in workflow contracts or trace views.

​
Webhook configuration

Webhook settings are managed from the Webhooks resource section. From Settings → Webhooks, you can view all provisioned webhook URLs, rotate signing secrets, and see which workflow handles each webhook.

​
Project membership and roles

Project members are managed from Settings → Members. A full role-and-permission model covering capability scoping and per-resource access is forthcoming; V1 roles are:
RoleCan do
OwnerAll project actions, including deleting the project
EditorAuthor changes, initiate releases
Release approverApprove or reject release requests (cannot initiate)
ViewerRead-only access to contracts, traces, and the project overview
Member role assignments are separate from org-level roles.