> ## Documentation Index > Fetch the complete documentation index at: https://docs.corsa.finance/llms.txt > Use this file to discover all available pages before exploring further. # Workflow Scoping Skill > AI skill for translating a compliance policy into a grounded Corsa workflow description ready for implementation. ## Overview The **corsa-workflow-scoping** skill turns a **compliance policy** (a clause, obligation, or AML/CFT requirement) into a **1–2 paragraph workflow description** that a downstream agent — or a developer using the **corsa-workflow-authoring** skill — can implement directly. It knows exactly what Corsa workflows can and cannot do, so it never describes features that don't exist and always flags capability gaps explicitly. ### What It Helps With * Extracting the trigger, steps, and compliance obligations from a policy clause * Mapping policy requirements to Corsa workflow capabilities * Identifying what falls outside the workflow engine (e.g. real-time transaction blocking belongs to the rules engine) * Producing concise, implementation-ready descriptions *** ## Quick Start After installing the skill, ask your coding tool questions like: * *"Scope a workflow for: 'when a client reaches HIGH risk, run EDD within 3 business days'"* * *"Translate our AML Policy §5.3 on dormant client re-activation into a Corsa workflow spec"* * *"Can a workflow freeze a transaction in real time?"* * *"What should be a workflow vs. a transaction monitoring rule?"* *** ## What the Skill Knows ### The Two-Step Workflow ``` corsa-workflow-scoping → grounded workflow description corsa-workflow-authoring → valid workflow definition + deployment ``` Use this skill first to produce the spec, then hand it to **corsa-workflow-authoring** for implementation. ### Workflow vs. Rule — The Key Distinction **Rules** evaluate synchronously per transaction and can block/freeze transactions in real time. **Workflows** react *after* events and orchestrate follow-up actions — screening, risk assessment, notifications, case opening, AI analysis. Use workflows for everything except real-time transaction blocking. ### What Workflows Can Express * **Event triggers**: entity created/updated (individual client, corporate client, alert, case, transaction) with field-level filters * **Scheduled triggers**: periodic scan of individual or corporate clients matching filters * **Steps**: client screening, PEP/sanctions re-screening, risk assessment, document/information requests, periodic review tasks, alert/case creation, entity updates, analyst notifications (in-app, email, Slack), client emails, AI/Copilot analysis, outbound webhooks * **Branching**: conditional fan-out based on entity fields or prior step outputs (e.g. AI verdict) ### What Workflows Cannot Express (Capability Gaps) | Policy requirement | Correct approach | | ------------------------------------------------- | ----------------------------------------------------------------------- | | Real-time transaction blocking / freeze | Transaction monitoring **rule** | | Custom code / arbitrary scripts | AI analysis + branching, or flag as gap | | Scheduled scans on alerts, cases, or transactions | Only clients are schedulable | | Creating new clients or transactions | Only ALERT and CASE can be created; clients/transactions can be updated | | High-frequency fan-out on every transaction | Rate-limited; scope to rules instead | ### Output Format A 1–2 paragraph plain-English description containing: the trigger (event + filters, or schedule + population), the ordered steps and conditional branches, what records are created/updated, who is notified, and the compliance driver (policy citation + SLA/escalation/record-keeping obligations). No JSON, no node names — intent only, ready for implementation. *** ## Source View the full skill source with policy-to-capability mappings and worked examples.