This guide gives an AI agent the rules and sequence for preparing a Lumail account for Lumail 2.0.0. The central change is simple: **marketing email belongs in Workflows, not in the transactional email API or SMTP.**

<AgentPrompt
  label="Prepare this account for Lumail 2.0.0"
  prompt="Read https://lumail.io/docs/ai-integration/prepare-account-2-0.md, then call get_skill with type workflow before changing anything. Audit the current Lumail account and the connected application. Classify every email as transactional or marketing. Keep immediate user-requested messages transactional. Move newsletters, nurture sequences, product announcements, promotions, and other marketing communication into Lumail Workflow drafts. Every marketing EMAIL step must include visible branding, a specific reason-for-sending sentence, the organization address, and an unsubscribe link. Reuse existing snippets when possible. Do not publish, activate, enroll subscribers, schedule, or send without my explicit approval. Return the audit, the drafts created or changed, and everything still requiring approval."
/>

## Non-negotiable routing rule

Classify the purpose of the message before choosing a Lumail API.

| Message           | Correct Lumail path                                  | Examples                                                                           |
| ----------------- | ---------------------------------------------------- | ---------------------------------------------------------------------------------- |
| **Transactional** | Transactional API, SDK `lumail.emails.send`, or SMTP | OTP, password reset, receipt, requested export, security alert                     |
| **Marketing**     | Lumail Workflow with one or more `EMAIL` steps       | Welcome nurture, newsletter, educational sequence, product announcement, promotion |

Do not use the transactional endpoint as a shortcut for marketing, even when the application already has the recipient's email address. Adding a delay, a promotional subject, or an unsubscribe link does not turn a transactional send into a compliant marketing workflow.

A message is transactional only when it is expected as the direct result of a recipient action and its primary purpose is to complete or confirm that action. If the primary purpose is engagement, education, retention, or sales, route it through a Workflow.

## What a prepared account contains

Before the agent reports the migration as ready, the account should have:

1. A verified sender for every Workflow email.
2. A reusable branded header or footer snippet.
3. A specific reason-for-sending line in every marketing email.
4. A physical address and unsubscribe link in every marketing email.
5. Workflow drafts for every marketing lifecycle.
6. A documented trigger for each workflow, such as subscriber created, tag added, event received, or manual enrollment.
7. Test evidence for every email and graph path.

Drafts are preparation. Publication and activation are separate, approval-gated actions.

## Phase 1: audit without sending

Start read-only. Do not create a workflow until the current state and the connected application's sends are understood.

1. Call `get_skill({ type: "docs", page: "ai-integration/prepare-account-2-0" })`.
2. Call `get_skill({ type: "workflow" })` and use the returned live schema.
3. Read `get_organization_settings`, `get_email_senders`, `get_writing_style`, and `get_email_snippets`.
4. List existing Workflows and read each relevant workflow with `get_workflow`.
5. Search the connected application for transactional API, SDK, and SMTP sends.
6. Produce an inventory with one row per email: trigger, purpose, audience, current path, required path, and migration action.

Use this decision table during the audit:

| Current email                           | Classification | Action                                             |
| --------------------------------------- | -------------- | -------------------------------------------------- |
| Sign-in code sent after a login request | Transactional  | Keep on transactional send                         |
| Receipt sent immediately after payment  | Transactional  | Keep on transactional send                         |
| Welcome education after signup          | Marketing      | Add subscriber/tag, then enter a Workflow          |
| Trial tips over several days            | Marketing      | Build a timed Workflow                             |
| Product launch announcement             | Marketing      | Use a Workflow and an eligible subscribed audience |
| “We miss you” re-engagement             | Marketing      | Use a Workflow with clear exit conditions          |

If the purpose is mixed, treat the message as marketing or split it into one necessary transactional message and a separate marketing workflow.

## Phase 2: create reusable email identity

Read existing snippets before creating another one. Prefer one shared header and one shared compliance footer so all Workflow emails stay consistent.

### Clear branding

Every marketing email must make the sender identifiable in a few seconds. Include at least one visible identifier:

- Organization or product name
- Recognizable logo with useful alt text
- Website domain displayed as text

Put branding near the top when possible. A compact footer is acceptable for personal, text-first email, but the identity must remain readable. Follow the complete [Clear Branding guide](/docs/tutorials/clear-branding).

### Clear reason for sending

Every marketing email must explain the real action that placed the subscriber in this audience:

> You're receiving this email because you subscribed to the Acme newsletter at acme.com.

For several legitimate sources, list the real possibilities:

> You're receiving this email because you subscribed through acme.com, completed one of our quizzes, or joined an Acme program.

Do not use circular wording such as “because you subscribed to my emails” or “for marketing purposes.” Follow the complete [Reason for Sending guide](/docs/tutorials/reason-for-sending).

### Required marketing footer

The reusable footer must contain all three:

1. The reason-for-sending sentence.
2. The organization address with `{{org-adresse}}`.
3. A visible unsubscribe link using `{{unsubscribeUrl}}`.

Use `get_email_snippets` and `get_email_snippet` before `create_email_snippet` or `update_email_snippet`. Updating a shared snippet changes every email that uses it, so report the affected snippets and Workflows before saving.

## Phase 3: move marketing into Workflow drafts

For each marketing lifecycle:

1. Define the entry event and eligible subscriber status.
2. Reuse an existing draft or call `create_workflow` with a descriptive name.
3. Read the new or existing workflow with `get_workflow` and keep its exact `updatedAt` value.
4. Build the complete graph with triggers, waits, `EMAIL` steps, branches, goals, exits, and edges.
5. Put complete inline email content on each `EMAIL` step, including branding and the required footer.
6. Call `configure_workflow_draft` once with the complete graph and `expectedUpdatedAt`.
7. Read the workflow again and verify the saved graph and every owned email.

`configure_workflow_draft` is the safe preparation tool: it validates and saves the draft atomically, but it never publishes, activates, enrolls, or sends.

Do not call `create_campaign` for a Workflow email. Each `EMAIL` step owns its internal email content.

## Phase 4: connect the application

The application should provide subscriber state and events, not send the marketing email itself.

Typical integration flow:

```text
User action in the app
        ↓
Create or update the Lumail subscriber
        ↓
Add the trigger tag or track the expected event
        ↓
Lumail Workflow enrolls the eligible subscriber
        ↓
Workflow waits, branches, sends, and exits
```

Public signups should respect double opt-in. With double opt-in enabled, subscriber-created and tag-added workflows wait until the subscriber confirms. Never put `skipDoubleOptIn: true` on a public or client-side form.

Keep **Add transactional recipients to the marketing list** off unless the organization has a valid marketing-consent reason. Receiving an OTP or receipt does not make someone a marketing subscriber.

## Phase 5: test and stop for approval

Before requesting publication:

1. Validate every graph path and branch.
2. Run a dry test with a test subscriber.
3. Send test copies of every Workflow email only to the approved test address.
4. Check mobile rendering, links, variables, dark mode, sender, branding, reason for sending, address, and unsubscribe.
5. Confirm **Branding** is `5/5` and **Reason for sending** is `10/10` in Content checks.
6. Read the Workflow again and report its status as `DRAFT`.

Then stop. `publish_workflow`, activation, enrollment, scheduling, and real sending require explicit human approval. Never infer approval from “prepare,” “migrate,” “configure,” or “make it ready.”

## Agent completion report

Return a concise report with:

- Transactional sends kept in the application
- Marketing sends removed or queued for removal from transactional code
- Workflow drafts created or updated
- Trigger and audience for each Workflow
- Shared snippets created or reused
- Branding and reason-for-sending evidence for every email
- Test results and unresolved validation errors
- Exact actions still awaiting approval

Do not report the account as migrated if marketing remains on `lumail.emails.send`, `/api/v2/emails`, `/api/v1/emails`, or SMTP.

## Related documentation

- [Migration to high deliverability emails](/docs/tutorials/migration-to-high-deliverability-emails)
- [Clear Branding](/docs/tutorials/clear-branding)
- [Reason for Sending](/docs/tutorials/reason-for-sending)
- [Workflow Getting Started](/docs/workflows/workflow-getting-started)
- [Workflow Email Steps](/docs/workflows/workflow-email-step)
- [Publishing and Versions](/docs/workflows/workflow-publishing)
- [Tools API](/docs/ai-integration/tools-api)