> For the complete documentation index, see [llms.txt](https://docs.complycube.com/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.complycube.com/documentation/product-guides/compliance-studio/lifecycle-triggers.md).

# Lifecycle Triggers

Automate ongoing customer due diligence. Schedule KYC reviews, request updated documents, and respond to risk changes throughout the client lifecycle.

### Lifecycle Triggers Overview

Lifecycle Triggers let you **automate follow-up actions** when **client information**, **verification status**, or **risk** changes. Use them to keep **customer due diligence** up to date after onboarding, from **document renewal** and **periodic KYC reviews** to **annual attestations** and **screening escalations**.

Choose an **event**, define **which clients** it applies to, and configure the **actions** to take. Actions can run **automatically** or wait for a **reviewer’s approval**. Every trigger execution is recorded in the **activity log** with the **configuration version** that produced it.

Lifecycle Triggers work with [Workflows](/documentation/product-guides/compliance-studio/workflows.md), [Smart Forms](/documentation/product-guides/compliance-studio/smart-forms.md), [AML Risk Scoring](/documentation/product-guides/due-diligence-tools/risk-profile.md), and [Advanced Case Management](/documentation/product-guides/due-diligence-tools/advanced-case-management.md). For example, a trigger can send a review workflow containing a Smart Form to collect **updated customer declarations**.

<figure><img src="https://1615271746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyFKMqftsmT6qln9zo5y%2Fuploads%2FeDIYIZk6WMPL2lmBwWAy%2Flifecycle-triggers.png?alt=media&amp;token=283839fe-3e47-406e-b0ee-8211b0861be2" alt="Lifecycle Triggers dashboard showing active and paused triggers, approval modes, and recent activity."><figcaption><p>Lifecycle Triggers - Monitor your lifecycle triggers and identify actions awaiting review or attention.</p></figcaption></figure>

### Common use cases

<table data-search="false"><thead><tr><th>Use case</th><th>How lifecycle triggers help</th></tr></thead><tbody><tr><td><strong>ID document renewal</strong></td><td>Request a new identity document before the current one expires and escalate after expiration.</td></tr><tr><td><strong>Periodic KYC reviews</strong></td><td>Schedule customer reviews at intervals based on risk level.</td></tr><tr><td><strong>Recurring attestations</strong></td><td>Ask customers to reconfirm declarations or provide updated information through a workflow.</td></tr><tr><td><strong>Risk-based follow-up</strong></td><td>Start a review when a client’s risk level rises or a linked country’s risk score changes.</td></tr><tr><td><strong>Screening escalations</strong></td><td>Create a case or notify reviewers when continuous monitoring identifies a new potential match.</td></tr><tr><td><strong>Incomplete verification journeys</strong></td><td>Remind customers to finish a flow and escalate overdue requests.</td></tr><tr><td><strong>Client record changes</strong></td><td>Respond to changes in identity details, contact information, or client stage.</td></tr></tbody></table>

### How Lifecycle Triggers work

A trigger has four parts:

| Part     | What you configure                                         | Example                                               |
| -------- | ---------------------------------------------------------- | ----------------------------------------------------- |
| **When** | The event that starts the trigger.                         | An identity document expires in 30 days.              |
| **Who**  | The clients the trigger applies to.                        | Individuals with a High or Very High risk level.      |
| **Then** | The actions to take.                                       | Send a re-verification flow and create a review case. |
| **How**  | Approval requirements and the cooldown between executions. | Require approval and set a 30-day cooldown.           |

Each time a trigger fires for a client, it creates an **execution**, referred to as a **firing** in the Portal. One execution can contain **several actions**, such as sending a flow and notifying your team.

**Date-based events** are checked **once a day**. **Change-based events**, such as a risk change or new screening match, fire **shortly after the change occurs**.

{% hint style="info" %}
Lifecycle Triggers determine **when follow-up actions run**. [Workflows](/documentation/product-guides/compliance-studio/workflows.md) define the **verification journey**, and [Smart Forms](/documentation/product-guides/compliance-studio/smart-forms.md) define the **information collected within it**.
{% endhint %}

### Creating a lifecycle trigger

{% @arcade/embed flowId="qNFV8lFnGyQkSujbyUG6" url="<https://app.arcade.software/share/qNFV8lFnGyQkSujbyUG6>" %}

In the ComplyCube Portal, navigate to [Lifecycle Triggers](https://portal.complycube.com/triggers) and click **New trigger**.

{% hint style="info" %}
Triggers are specific to their **environment**. **Sandbox** triggers act on sandbox clients; **live** triggers act on live clients. Referenced workflows and case templates must exist in the **same environment**.
{% endhint %}

Start with a **template** or select **Start from scratch**. Give the trigger a clear name and, optionally, a description explaining its purpose. Templates that require a service outside your plan are marked **Not in your plan**.

<table data-search="false"><thead><tr><th>Template</th><th>Purpose</th></tr></thead><tbody><tr><td><strong>Re-verify before an ID expires</strong></td><td>Send a re-verification flow 30 days before expiration and a webhook on the expiration date.</td></tr><tr><td><strong>Risk-based periodic review</strong></td><td>Start with review intervals of six months for Very High risk, one year for High risk, two years for Medium risk, and three years for Low risk.</td></tr><tr><td><strong>Review when country risk rises</strong></td><td>Notify your team when a country linked to a client moves to High risk.</td></tr><tr><td><strong>Annual attestation</strong></td><td>Request a yearly self-declaration and create a case if it becomes overdue.</td></tr><tr><td><strong>Escalate screening matches</strong></td><td>Create a case and notify your team about a new PEP or sanctions match from monitoring.</td></tr><tr><td><strong>Chase unfinished flows</strong></td><td>Remind customers three days before their deadline and on the deadline, then create a case after seven overdue days.</td></tr><tr><td><strong>Re-review when risk increases</strong></td><td>Send a review flow and notify your team when a client’s risk level increases.</td></tr></tbody></table>

Adjust the template to your review process. Template intervals are starting settings you can change.

<figure><img src="https://1615271746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyFKMqftsmT6qln9zo5y%2Fuploads%2F2gkHVembPJPEVOe3LkDM%2Flifecycle-triggers-template.png?alt=media&amp;token=87bdfda5-74b1-46b8-84db-5d37f41a8e6e" alt="New lifecycle trigger screen showing templates and the Start from scratch option"><figcaption><p>Lifecycle Triggers - Start with a template or configure a lifecycle trigger from scratch.</p></figcaption></figure>

#### **Step 1: Choose when the trigger runs**

In **When**, select the event to watch. Each trigger watches **one event**.

<table data-search="false"><thead><tr><th>Event</th><th>When it fires</th></tr></thead><tbody><tr><td><strong>Periodic review due</strong></td><td>A client reaches their next review date, based on the configured risk-based schedule.</td></tr><tr><td><strong>Attestation due</strong></td><td>A client is due to complete an attestation workflow again.</td></tr><tr><td><strong>Client data changed</strong></td><td>A watched identity, address, or contact field changes.</td></tr><tr><td><strong>New screening match</strong></td><td>Continuous monitoring identifies a new potential PEP, sanctions, watchlist, or adverse media match.</td></tr><tr><td><strong>Risk changed</strong></td><td>A client’s risk level changes or the risk score of a linked country changes.</td></tr><tr><td><strong>Stage changed</strong></td><td>A client moves between standard or custom stages.</td></tr><tr><td><strong>Check completed</strong></td><td>A supported check completes with an outcome you selected.</td></tr><tr><td><strong>Check validity expiring</strong></td><td>A supported check reaches the end of your configured validity period.</td></tr><tr><td><strong>Document expiring</strong></td><td>An identity document approaches or passes its expiration date.</td></tr><tr><td><strong>Flow not completed</strong></td><td>A flow approaches or passes its completion deadline.</td></tr></tbody></table>

**Date-based events and fire points**

For **date-based events**, choose one or more **fire points**: the days before, on, or after the relevant date when the trigger should run.

| Events                                             | Available fire points                                              |
| -------------------------------------------------- | ------------------------------------------------------------------ |
| **Document expiring**, **Check validity expiring** | 60, 30, 14, or 7 days before; **On expiry**; 7 or 30 days after.   |
| **Periodic review due**, **Attestation due**       | 30, 14, or 7 days before; **On the due date**; 7 or 30 days after. |
| **Flow not completed**                             | 7, 3, or 1 day before; **At the deadline**; 7 or 30 days overdue.  |

Use fire points to stage your follow-up. For example, request a replacement document 30 days before expiration and create a case seven days after expiration. In **Then**, select which actions run **before**, **on**, or **after** the date.

#### **Step 2: Choose which clients are included**

In **Who**, narrow the trigger to the relevant clients. Leave a filter empty to include **all available values** for that filter.

| Filter                | What it controls                                                                                                                                                    |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Client type**       | Individuals, companies, or both, subject to the event’s supported client types.                                                                                     |
| **Risk level**        | Selected risk levels, including clients without a risk level. Requires risk profiles in your plan.                                                                  |
| **Country**           | The countries to include.                                                                                                                                           |
| **Match on**          | The country fields to evaluate: address, nationality, birth country, or incorporation country. A client matches if any selected field contains an included country. |
| **Client stage**      | The client’s stage when the trigger fires.                                                                                                                          |
| **Onboarded through** | The workflows through which the client was onboarded.                                                                                                               |

<figure><img src="https://1615271746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyFKMqftsmT6qln9zo5y%2Fuploads%2F8JyEefWGfPgXG1KRQgYJ%2Flifecycle-triggers-who.png?alt=media&amp;token=567b8bc5-dc9f-4233-b4fc-9c50c8684d4d" alt="Lifecycle trigger filters for client type, risk level, country, stage, and onboarding workflow."><figcaption><p>Lifecycle Triggers - Limit a trigger to the client population that needs follow-up.</p></figcaption></figure>

#### **Step 3: Configure the actions**

In **Then**, add **up to 10 actions**. Actions run **in the order listed**. For date-based events, each action’s **Runs** setting determines whether it runs before, on, or after the date. For other events, actions run each time the trigger fires.

| Action                        | What it does                                                                                               |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Send re-verification flow** | Email the client a link to the selected workflow.                                                          |
| **Remind client**             | Resend the existing flow link while it is valid. Available for **Flow not completed** only.                |
| **Create a case**             | Create a case using a case template and assign it to a team member. Requires case management in your plan. |
| **Send notification**         | Notify yourself or selected team members in the Portal, with an optional email notification.               |
| **Set client stage**          | Move the client to a selected standard or custom stage.                                                    |
| **Update client metadata**    | Set a key and value on the client record.                                                                  |
| **Send webhook**              | Send a `trigger.fired` event to subscribed webhook endpoints.                                              |

<figure><img src="https://1615271746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyFKMqftsmT6qln9zo5y%2Fuploads%2FA83paGOCcw54XhTeVwOl%2Flifecycle-triggers-then.png?alt=media&amp;token=37c4e6cc-2688-409f-9a4c-146f62b90d90" alt="Trigger actions configured to send a re-verification flow before expiration and create a case afterward."><figcaption><p>Lifecycle Triggers - Combine customer follow-up with internal review and escalation actions.</p></figcaption></figure>

**Sending flows and reminders**

For **Send re-verification flow**, select the workflow and an email template. Available templates depend on the event and include **Identity verification**, **Document renewal**, **Periodic review**, and **Confirm details**.

The workflow can include **document verification**, a **Smart Form** for updated declarations, or other steps required by your review process.

Configure no reminders or **up to three reminders**, with an interval of 1, 2, 3, 5, or 7 days. Set the link to expire after **3, 7, or 14 days**. Select **Preview** to review the initial email and reminder on desktop or mobile.

<figure><img src="https://1615271746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyFKMqftsmT6qln9zo5y%2Fuploads%2FumgYASLTIHOHmN2x8JFp%2Flifecycle-triggers-email-preview.png?alt=media&amp;token=bebfaf11-c305-4167-9a3c-29431266c947" alt="Document renewal email preview with desktop, mobile, email, and reminder views."><figcaption><p>Lifecycle Triggers - Preview the message customers will receive before enabling email actions.</p></figcaption></figure>

**Updating client stages**

A stage update is recorded in the client’s **stage history** and can start other **Stage changed** triggers. A trigger does not respond to its own stage change, cannot set the stage it watches for, and cannot set an archived stage. Stage-change chains are limited to prevent loops.

#### **Step 4: Set approvals and cooldowns**

In **How**, choose how actions are authorized:

| Mode               | Behavior                                                                                 |
| ------------------ | ---------------------------------------------------------------------------------------- |
| **Automatic**      | Actions run when the trigger fires.                                                      |
| **Needs approval** | The execution enters the **Approvals** queue. Actions wait until a reviewer approves it. |

Set **Don’t fire again for the same client within** to 1, 3, 7, 14, 30, 60, or 90 days. This **cooldown** applies to **that trigger and client**. It is not a shared cooldown across different triggers.

Fire points for the same target date are **not blocked by the trigger’s cooldown**. Executions are also skipped when the client has a **flow in progress**, helping avoid overlapping flow requests.

<figure><img src="https://1615271746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyFKMqftsmT6qln9zo5y%2Fuploads%2FsfhrazUUQGs815eh78zo%2Flifecycle-triggers-how.png?alt=media&amp;token=293c5fb6-7f41-4e5c-b800-feb72cd1a419" alt="Trigger approval mode set to Needs approval with a 30-day cooldown."><figcaption><p>Lifecycle Triggers - Control reviewer approval and the interval between repeat executions.</p></figcaption></figure>

**Step 5: Handle existing matches**

For date-based events, choose how to handle clients who already match when you enable the trigger:

* **Only new matches**: Start from today without including clients who already match.
* **Include them**: Add existing matches to the approval queue for review before actions run. This also applies when the trigger’s mode is **Automatic**.

**Review and save**

Check the **Review and save** summary. If a configuration issue prevents saving, select **Fix** to open the relevant field.

Add a note for the version history. Use **Turn the trigger on** to enable it, or leave this off to save it without running it. If you included existing matches, review how they will enter the approval queue before confirming.

<figure><img src="https://1615271746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyFKMqftsmT6qln9zo5y%2Fuploads%2FM41FQqNxdHoc75U3zYSG%2Flifecycle-triggers-review.png?alt=media&amp;token=b477733d-41f2-4eae-8447-a53a81085454" alt="Review and save panel summarizing a lifecycle trigger’s event, clients, actions, and approval settings."><figcaption><p>Lifecycle Triggers - Review the complete trigger configuration before saving or enabling it.</p></figcaption></figure>

### Testing lifecycle triggers

Use **More actions** > **What would fire?** on a trigger’s detail page to select a day and preview which clients would match, with the reason for each match. This preview **does not send messages or change records** and is available in both **live** and **sandbox**.

<figure><img src="https://1615271746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyFKMqftsmT6qln9zo5y%2Fuploads%2F2xrfLtvGdgefpztRxdl8%2Flifecycle-triggers-what-would-fire.png?alt=media&amp;token=e13e7497-a549-49dd-8145-53eae7122067" alt="What would fire preview listing matching clients and reasons for a selected date."><figcaption><p>Lifecycle Triggers - Check a trigger’s matching clients before enabling it.</p></figcaption></figure>

In sandbox, you can also use:

* **Test this trigger**: Select a sandbox client and run the trigger’s actions. Test executions are marked **Test** and excluded from trigger statistics.
* **Run today’s check now**: Run the daily check immediately.

{% hint style="info" %}
Sandbox tests **execute actions**, including cases, notifications, and webhooks. **Email delivery is restricted** to addresses on your own domain, with a daily test email limit. Use the **Test** dialog’s guidance to simulate an email bounce.
{% endhint %}

### Managing triggers and versions

The **Triggers** tab shows each trigger’s status, approval mode, number of executions in the last 30 days, and most recent execution. Summary tiles show active triggers and recent execution and failure counts.

Open a trigger to review **How it works**, statistics, **Version history**, and **Recent activity**. Select a statistics tile to open the corresponding activity.

<figure><img src="https://1615271746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyFKMqftsmT6qln9zo5y%2Fuploads%2FOYw1engJqtT1XlD5prBZ%2Flifecycle-triggers-details.png?alt=media&amp;token=9c4e58c8-3698-43d5-990e-15d0570ab974" alt="Lifecycle trigger details showing configuration, statistics, version history, and recent activity."><figcaption><p>Lifecycle Triggers - Review a trigger’s configuration and execution history in one place.</p></figcaption></figure>

Every save creates a **new version**. New executions use the updated configuration; executions already waiting for approval **retain the version they were queued under**.

| Operation     | Effect                                                                                |
| ------------- | ------------------------------------------------------------------------------------- |
| **Edit**      | Update the configuration and save a new version.                                      |
| **Pause**     | Stop new executions and cancel pending approvals.                                     |
| **Resume**    | Turn a paused trigger back on.                                                        |
| **Duplicate** | Create a copy for a different configuration.                                          |
| **Delete**    | Stop the trigger and cancel pending approvals. Historical activity remains available. |

### Reviewing approvals

Open **Approvals** to review queued executions. Each entry shows the client, why the trigger fired, the planned actions, and when it was queued.

* **Approve** runs the planned actions using the configuration version recorded when the execution was queued.
* **Reject** prevents the actions from running. Add an optional reason for the activity log.

Select multiple entries or **Select all** to approve or reject them together. Pausing or deleting a trigger **cancels its pending approvals**.

<figure><img src="https://1615271746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKyFKMqftsmT6qln9zo5y%2Fuploads%2F9ZwWBf4cUYagB9XhwLOD%2Flifecycle-triggers-approval.png?alt=media&amp;token=0293896c-1025-4994-ad5a-41d76b8c2ac4" alt="Approvals queue with client details, trigger reasons, planned actions, and bulk approval controls."><figcaption><p>Lifecycle Triggers - Review planned actions before authorizing customer contact or record updates.</p></figcaption></figure>

### Resolving actions that need attention

The **Needs attention** tab lists **failed actions** and client emails that **could not be delivered**. Review the problem and its cause, then choose an available resolution:

* **Fix email** updates the client’s email address and resends the email.
* **Retry** runs failed actions again after you address the cause.
* **Dismiss** removes the entry from the queue, with an optional note. Its history remains in the activity log.

| Issue                                         | Resolution                                                             |
| --------------------------------------------- | ---------------------------------------------------------------------- |
| Missing or undeliverable client email         | Use **Fix email** to enter a deliverable address.                      |
| Brand name not configured                     | Set a brand name in **Settings** > **Branding**, then retry.           |
| No endpoint subscribed to `trigger.fired`     | Subscribe an endpoint under **Developers** > **Webhooks**, then retry. |
| Case management unavailable on your plan      | Remove the case action or contact your Account Manager.                |
| Selected notification recipients are inactive | Update the trigger to select active team members.                      |
| Flow link expired before a reminder           | Send a new flow.                                                       |

### Activity log and audit trail

The **Activity log** records trigger executions, approvals, rejections, skips, and failures, including the **trigger version** used. For email actions, it also records sending, delivery, delivery failures, and resends.

Filter by trigger, outcome, and time period, or search by client or detail. Select **Export** to download the filtered activity as **CSV**. The export includes dates, client IDs, trigger versions, related check IDs, and reasons.

#### Connecting your systems with webhooks

Add a **Send webhook** action to notify your systems when a lifecycle trigger runs for a client. Your webhook endpoint must subscribe to `trigger.fired`.

For **Needs approval** triggers, the event is sent after the execution is approved. The payload identifies the trigger, configuration version, execution, and client, along with the reason the trigger fired.

Use these events to connect lifecycle activity to your CRM, back office, or other internal systems.

See the Lifecycle trigger payload for event attributes and examples, and the Webhooks Guide for integration guidance..

### Permissions and limits

**Owners** and **administrators** can approve and reject executions by default. With [Custom Roles](/documentation/access-management/teams-and-user-roles.md#custom-roles), you can grant permissions separately:

| Permission                                      | Access                                               |
| ----------------------------------------------- | ---------------------------------------------------- |
| **View lifecycle triggers**                     | View triggers, detail pages, and the activity log.   |
| **Create and edit lifecycle triggers**          | Create, edit, pause, duplicate, and delete triggers. |
| **Run and test lifecycle triggers**             | Use sandbox test and daily check controls.           |
| **Approve or reject lifecycle trigger actions** | Review and decide queued executions.                 |

### Best practices

* **Preview matching clients** before enabling a trigger, especially when including existing matches.
* **Start with approval** while validating a new configuration, then enable automatic actions when appropriate.
* **Align review schedules with your process** using risk levels, review workflows, and a clear date source.
* **Plan follow-up stages** so customer requests and internal escalations run at appropriate fire points.
* **Coordinate overlapping triggers** because each trigger has its own cooldown.
* **Test in sandbox** before recreating the configuration in live.
* **Record meaningful version notes** and review **Needs attention** regularly.

### Frequently asked questions

<details>

<summary>What is a lifecycle trigger in KYC and AML compliance?</summary>

A lifecycle trigger automates follow-up during the customer relationship.

It can start periodic KYC reviews, request renewed documents, and respond to risk or screening changes. This supports ongoing customer due diligence after onboarding.

</details>

<details>

<summary>What is the difference between Lifecycle Triggers and Workflows?</summary>

Lifecycle Triggers determine **when** follow-up actions run.

[Workflows](/documentation/product-guides/compliance-studio/workflows.md) define the verification journey a customer completes. A trigger can send a workflow when its event and client filters match.

</details>

<details>

<summary>Which events can start a lifecycle trigger?</summary>

Lifecycle Triggers can start from date-based and change-based events.

Examples include document expiry, periodic review dates, risk changes, new screening matches, client stage changes, completed checks, and incomplete flows.

</details>

<details>

<summary>Can Lifecycle Triggers automate periodic KYC reviews?</summary>

Yes.

Use **Periodic review due** to set review intervals by client risk level.

A trigger can send a [Workflow](/documentation/product-guides/compliance-studio/workflows.md) with verification checks and [Smart Forms](/documentation/product-guides/compliance-studio/smart-forms.md). It can also notify your team or create a case.

</details>

<details>

<summary>Do Lifecycle Triggers replace continuous AML monitoring?</summary>

No.

Continuous monitoring identifies new potential screening matches. A **New screening match** trigger determines the follow-up, such as opening a case or notifying a reviewer.

Continuous monitoring must be enabled for the client. See [AML Screening](/documentation/product-guides/watchlist-pep-and-adverse-media/aml-screening-check.md).

</details>

<details>

<summary>Can I review actions before a customer is contacted?</summary>

Yes.

Select **Needs approval** to queue executions for review. **No actions run** until a reviewer approves them.

Existing matches enter the approval queue when included for a date-based trigger. This also applies in **Automatic** mode.

</details>

<details>

<summary>Why did a client not receive a flow?</summary>

Check **Approvals**, **Needs attention**, and the **Activity log** first.

The execution may await approval, the email may have failed, or the trigger may be skipped. Cooldowns and flows already in progress can also prevent delivery.

Check the client filters, fire points, and trigger status. Use **What would fire?** to preview matching clients.

</details>

<details>

<summary>What happens to pending approvals when I change a trigger?</summary>

Editing creates a new version for future executions.

Existing approvals retain the version that queued them. Pausing or deleting a trigger **cancels pending approvals**.

</details>

<details>

<summary>Do I need to write code to use Lifecycle Triggers?</summary>

No.

You can configure and manage triggers in the Portal.

Developers can use the **Send webhook** action to connect trigger activity to other systems.

</details>

### Related topics

* [Workflows](/documentation/product-guides/compliance-studio/workflows.md) for verification and review journeys.
* [Smart Forms](/documentation/product-guides/compliance-studio/smart-forms.md) for updated customer data, declarations, and documents.
* [AML Risk Scoring](/documentation/product-guides/due-diligence-tools/risk-profile.md) for ongoing client risk assessment.
* [Advanced Case Management](/documentation/product-guides/due-diligence-tools/advanced-case-management.md) for managing reviews and escalations.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.complycube.com/documentation/product-guides/compliance-studio/lifecycle-triggers.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.