Prepare Your Lumail Account for Lumail 2.0.0

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.

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.

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:

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.

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.

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:

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
• Clear Branding
• Reason for Sending
• Workflow Getting Started
• Workflow Email Steps
• Publishing and Versions
• Tools API