Start in Migma by defining what each onboarding email should ask a user to do. Then give the workflow owner an equally clear rule for when that request is no longer useful. A setup reminder can be beautifully designed and still be wrong for someone who finished setup yesterday.
This Migma-published guide focuses on exit rules for teams using Loops. It provides an original review worksheet and test scenarios, rather than another fixed-day email schedule. Official documentation was checked on October 15, 2026. Migma handles the creative review described here; the product and sending owners must implement and verify the contact state and workflow behavior.
Describe completion in a way the product can verify
Write one sentence that defines the action behind the reminder. For an example project-management app, the useful milestone might be publishing a first project with at least one task. Signing in or opening the welcome email would not establish that outcome.
Next, name the source of that fact. A product event, a stored contact property, and an email open are different signals. The product owner should explain how the sending platform receives the relevant state and how the team knows it arrived. A draft that says “finish your project” should not depend on a guess about whether the user has one.
Loops' onboarding examples guide describes mirroring completion into a contact property and checking it before remaining setup emails. Use your own product milestone rather than copying the example property without agreeing what it means.
Make a creative brief with an exit column
In Migma, prepare the approved copy, brand context, and action for each message. Add a small companion worksheet for the workflow owner. Keep the worksheet alongside the design version so reviewers can connect a sentence to the condition that makes it appropriate.
| Message purpose | Reader state that supports it | Stop or change the message when |
|---|---|---|
| Help create a first project | User has not completed the agreed milestone | Completion is recorded |
| Explain an unfinished connection | Connection is still missing and user can manage it | Connection works or the user lacks that role |
| Offer setup help | User is still eligible and remains blocked | Setup completes, permission changes, or the sequence ends |
| Introduce a useful next task | First milestone is complete | The next task is already done or irrelevant |
These are proposed rules for the example app, not measured results or a ready-made Loops configuration. Review them with the people who own the product's data before activating a workflow.
Check how far each audience filter applies
The current Loops branching documentation distinguishes “All following nodes” from “Next node only.” With the former, a contact who stops matching later is removed from the workflow. With the latter, the condition applies when the contact reaches the next node, and later changes do not remove them on that basis.
That scope matters when a user completes setup during a wait. A filter checked once near the start is not evidence that every later reminder remains relevant. Ask the workflow owner to show where the completion condition applies and what happens to a contact already waiting downstream.
Also inspect the actual branch version. Loops documents a change from older parallel matching to first-match behavior for new branches, with existing older branches retaining their logic until explicitly upgraded. Do not infer how a saved workflow behaves from a screenshot of the current documentation.
Keep role and completion separate
An invited teammate may be active without having permission to connect a company data source. A workspace owner may have connected it while another teammate was waiting for a reminder. The brief should identify whether completion belongs to the person, account, or workspace.
Use that distinction in the copy. “Connect your team's data source” may be a reasonable request for an administrator and a confusing request for an invited contributor. If the team lacks reliable role data, write a neutral path and ask the implementation owner to handle the unknown state deliberately.
The branch documentation says current branches evaluate filters from left to right and follow the first match. A right-most filter with empty conditions can provide a default path. Treat the design of that path as a real content decision: unknown data should not quietly become an unsupported accusation that setup is unfinished.
Test the user who changes state during the wait
Create a small acceptance sheet with fictional records. Have the authorized testing owner run it in an appropriate environment. Do not change a real customer's contact properties simply to obtain a screenshot.
One record should remain incomplete. Another should complete the milestone before the first reminder. A third should finish while waiting between reminders. A fourth should have missing state, and a fifth should represent a teammate who cannot perform the requested action.
For each scenario, record the expected message or exit, the observed workflow result, and the creative version involved. If a reminder still goes out after completion, investigate the state update and filter scope before changing the headline. Better wording cannot make an incorrect audience decision correct.
Match the destination email to the approved design
Review the message in Migma for the right action and a helpful explanation of the unfinished step. Use Email Preflight to inspect the creative. Keep the email short enough that the request and support route are easy to find.
Where an HTML handoff fits, use Migma's export options and have the implementer adapt the destination template. This does not claim a native Migma-to-Loops export connector. Verify the final button destination with the correct user role and sample state; a link can work technically while leading someone to a screen they cannot use.
Separate that creative review from workflow acceptance. The Migma draft shows what the team approved. The received test message and recorded workflow outcome show what the configured journey did.
End the reminder and choose the next useful conversation
Completion should end an obsolete setup request. It need not trigger another email immediately. Decide whether the user needs an acknowledgment, a later next-step guide, or simply time to use the product.
For the example app, a completed project might lead to a later collaboration tip, while an incomplete user gets a concise help offer. Those messages answer different needs and should have different briefs. Do not rename the same setup nudge and keep sending it.
Build the creative in Migma with the exit rule visible during review. Then ask the workflow owner to prove that the reminder stops for the right reason. A reliable onboarding sequence respects progress as carefully as it asks for it.
Frequently Asked Questions
Is opening an email a good onboarding completion rule?
An open is not proof that the product milestone is complete. Agree on a product action and verify how its state reaches the sending platform.
What happens if a user activates during a delay?
The intended result is to stop obsolete setup reminders. The workflow owner must verify current contact state and audience-filter scope for a contact already waiting.
Do all saved Loops branches use the same matching behavior?
No. Current documentation distinguishes new first-match branches from older branches that retain parallel behavior until explicitly upgraded. Inspect the saved workflow before assuming its logic.
Does this workflow require a native Migma-to-Loops connector?
No. Prepare and review creative in Migma, then adapt an appropriate export or reference in the destination. The implementation owner verifies the final template and workflow behavior.