Blueprints

A review policy, represented as a blueprint in the API, defines the requirements for a category of case. Manage policies under Case Management > Assignment > Review policies. Cases save the policy version in effect when they are opened, so later edits do not silently change an ongoing review. The editor submits the version it opened when you save. If another reviewer has published a newer version, the save returns a conflict and your draft stays open. Review the latest policy before applying your changes again. API integrations can send expected_version with a policy update for the same protection; a stale version returns 409 without changing the policy.

---

​

General settings

​

Automatic assignment

Automatic assignment selects an authorized reviewer with the fewest active cases across the organization, up to the configured capacity. Online officers are preferred when available; otherwise eligible offline officers can receive cases. When every eligible reviewer is at capacity, the case stays unassigned. Resolving a case or an officer coming online can pull a queued case when capacity is available.

​

Escalation and transfer

Escalation moves a case to a fixed target blueprint (its queue, its content configuration) in one action. Case transfer instead lets an officer pick any active blueprint of the same application to move a case to. Both are hidden from the case page unless the current blueprint enables them, and both are blocked server-side (400) if attempted while disabled. A blueprint cannot reference itself as its own escalation target or 4-eyes checker.

​

Connected sources

A blueprint’s right rail lists:

• Case creation sources: AML configs, transaction rules, and workflow nodes currently routing new cases into it, with shortcuts to each one.
• Receives escalation from: other blueprints whose escalation target points here.

​

Save and publish policy changes

Save draft stores your changes without affecting new or existing cases. A new policy stays unpublished and cannot be selected for a case or routing rule until you choose Publish. Reopening the editor restores the saved draft. Publish becomes available once the current edits have been saved. Publishing applies that version to new cases; existing cases retain their accepted review requirements. Version history records each published configuration, publication time, and publisher when known. Policies created before version history was available have their current baseline recorded on the next publication. Discard draft requires confirmation and returns the editor to the published configuration. Discarding a never-published draft deletes it. Draft saves and publication check both the published version and the draft revision. If someone else changes either, the server returns 409 and your open editor keeps its unsaved edits. A draft based on an older published policy must be reviewed against the current policy before publication. Direct API PATCH updates remain immediate publications and are also recorded in version history.

​

Routing-rule drafts

Routing rules use the same Save draft, Publish, Discard draft, and Version history actions. Saving a draft does not change the rule used for automatic assignment or the published-rule preview. Unpublished changes must be saved before they can be published. Publication checks that the selected review policy and team are still active and belong to the same application. If another editor changes the rule or its draft, the operation returns a conflict and preserves the newer work. New rules use Save draft first and remain inactive until Publish creates version 1. For API integrations, set publish=false when creating a policy or routing rule to use this lifecycle. Omitting the option preserves immediate creation for existing integrations.

​

Preset library

Install any of the four built-in presets from the review policy presets gallery. Installing copies the preset into your application as a fully editable blueprint, you can then change any setting freely without affecting the catalogue. Installing is idempotent per preset, so re-installing an already-installed preset is a no-op. None of the presets pre-configure assignment, escalation, 4-eyes, or transfer, those routing decisions are always yours to make per blueprint.

​

Case content

The Case content tab controls which tabs and fields appear on the case page, as six togglable sections: A blueprint with no sections enabled still shows the case Overview tab, just without the extra content blocks.

​

Deleting a blueprint

Deleting a blueprint always succeeds and does not touch its cases: existing cases keep their blueprint reference, and its settings (content sections, escalation, transfer, 4-eyes pairing) continue to apply to them. A deleted blueprint no longer appears in blueprint lists and can no longer be chosen as a transfer target. If a maker blueprint is deleted while one of its resolutions is pending 4-eyes approval, a rejected resolution leaves the case on the checker blueprint instead of returning it. To wind a blueprint down cleanly, transfer its active cases to another blueprint before deleting it.