Activate new signups

Follow up with new signups who have not created their first project. This guide uses Loopwell, a fictional project management product: wait two days after signup, check that person’s own projects, and email them only if they still have none.

You will build a reviewable draft with a clear decision: started → finish; not started → send the first-project email. maxinja can create the steps from your brief. You check the customer match, the query, the branch and the email before publishing.

Before you start

A contact schema for your users, a Project object schema, and a relationship identifying who created each project. A shared team account is not enough to establish ownership.
A signup event linked to the user it describes. In this example it is named Usersignedup; select your own equivalent in the trigger.
A brand kit, authenticated sending domain, and email subscription/topic eligibility for the contacts who will receive marketing email.
At least two representative contacts to inspect: someone with no own projects and someone who already created one. Include a teammate’s project to check that it does not count as the user’s work.

If you still need the data model, start with Set up your data. The field names in this guide describe the example; maxinja must use the actual relationships in your workspace.

The journey you will build

Stage	Customer decision
Signup event	Which person just signed up?
Find Records	Resolve that person’s contact for later steps.
Delay	Give them two days to get started.
Query	Count projects created by this person now.
If/Else	End the follow-up if that count is greater than zero.
AI	Prepare first-project guidance from the person’s role and stated goal.
Send Email	Use that guidance in the email to eligible contacts.

Query answers a factual question: how many projects exist? AI interprets the person’s goal to prepare guidance. The example keeps those jobs separate. If you only need personalized wording inside an email, you can use Adaptyle in the email instead of the separate AI step.

Start a new workflow
Open Workflows in the top navigation and choose New workflow. Name it “First project follow-up”.
Ask maxinja: “Build an unpublished workflow for Usersignedup. Find the user who signed up. Wait two days, then Query the number of projects created by that user, not their teammates. If the count is greater than zero, end the journey. Otherwise add an AI step that suggests a first project from their role and stated goal, then use its result in a marketing email. Keep it unpublished for review.”
Inspect the resulting canvas. The following steps describe the settings to check or configure yourself.
Pick what starts it
Choose Event Fired, then the signup event under When a … fires. Confirm that its user relationship points to the person who signed up.
Follow it with Find Records, selecting your user/contact schema. Ask for only the contact identified by this event, with a nonempty individual user identity that can be matched to a project creator. Enable Process each record separately so later steps receive one contact. This lookup should match exactly one person; a broad filter can start multiple follow-ups from one signup.
App appearanceView full size
The Event Fired trigger uses Usersignedup.
Wait, then check their own projects
Use an outgoing connection’s plus button to add Delay. Describe “Wait two days” and send the instruction to maxinja. Review its compiled explanation.
Add Query after the delay. Describe “Count Project records whose creator is the user from this signup event. Return zero when this user has no projects. Do not count projects created by other people in their account.”
Ask maxinja to name the result projectCheck, with a numeric projectCount and a boolean hasProject that is true only when the count is greater than zero. Inspect Compiled, Depends on and Reads: they should identify the Project schema and the creator relationship, using this run’s user. The earlier user lookup must exclude a missing user identity. A count of zero only has meaning for an identified person. A failed query is not a zero count.
Inspect the creator match in the compiled query, then check its dependencies.
Stop when the person has already started
Add If/Else. Describe “projectCheck.hasProject is true” and compile it. Leave If true unconnected so that path ends. Connect If false to the AI step below.
Check the wording and connections together. Reversing this condition would email the people who have already created a project.
Prepare first-project guidance
Add AI on the false branch. Under Expected data, select the user’s role and stated goal. Set Prompt to suggest one first project using only that context, with a short generic suggestion when context is missing. Do not ask the model to guess whether the person has already started; Query has answered that.
Ask maxinja to configure a Result shape containing a text field named suggestion, and name the step’s output firstProjectGuidance. Choose both Model and Thinking under AI settings. Web search and workspace data tools are unnecessary when the required facts are already supplied.
The result is guidance that later steps can reuse. This step does not send an email.
Set up the email
Set Sends to to the single user/contact found earlier. Open Email template, choose your editor and Marketing sending mode, then compose the first-project email with your brand kit. The template belongs to this step.
Insert the AI result with Liquid, using {{ firstProjectGuidance.suggestion }} for the output configured above. Keep the project-creation link in a fixed button. Check that the email’s data includes the AI output, then preview its layout using representative sample guidance. A content preview does not execute the preceding workflow steps.
Check the sender, subscription topic and recipient data. A message accepted by the email provider is not confirmation of delivery.
Publish to turn it on
Review the decision checks below and verify a controlled run before publishing the customer-facing version. Resolve blocking issues and read warnings. Publication makes this version live for qualifying signup events; it does not replay all historical signups.
If you are editing an existing workflow, its previous published version can still run while you change the draft. Publishing also resumes a paused workflow, including waiting runs on their original versions.

Review the customer decision

These are the expected outcomes to check, not results from the recorded draft:

Customer situation when Query runs	Expected behavior
No projects created by this person	Query returns a zero count; If false reaches AI and then the email. Sending still requires eligibility.
At least one project created by this person	Query returns a positive count; If true ends the journey.
A teammate created a project, but this person has none	Count remains `0`; their teammate’s work does not stop this follow-up.
Signup cannot resolve to a contact with a usable user identity	Find Records produces no match and that fan-out ends. Inspect the event/contact mapping.
Query cannot produce the declared result	Inspect the failure; do not substitute zero for missing evidence.

The Query runs after the delay, so it can see projects created during those two days. Its result describes that lookup; it is not a guarantee that nothing changes between the query and the email.

If your source of truth is a recorded activity rather than Project records, consider If/Else → Customer event history. It has a defined lookback, customer/correlation matching and late-event allowance. That is a different decision from counting current records; see event-history decisions.

Verify a controlled run

An email preview checks the message with sample data. To check the lookup and branch, execute the journey for test contacts:

Duplicate the workflow from its list menu and name the copy clearly. Keep the customer-facing original unpublished.
Restrict the copy's trigger to your test contacts. Remove its Send Email step while checking the decision; check that no other record changes or external actions remain. Shorten the test copy's delay and compile that change.
Publish the copy, then create a new qualifying signup event for each test contact. This is real execution and uses credits. Publication alone does not replay their old signup events.
Open Runs. Compare the resolved contact, Query's Received and Produced, and the If/Else path with the table above. For the zero-project contact, inspect the AI suggestion and repeat with a missing goal to check its generic answer.
Pause the copy after the checks. Apply any corrections to the original, preserve its intended two-day delay, and check the final email separately with Send test before publishing to customers.

Success is evidence for both paths: the customer with a project finishes without a reminder, while the customer without one reaches suitable guidance. The test copy's completed run does not establish that the original workflow has sent email.

Review the work it can create

Check the contact lookup and any For Each list. One trigger can create many child runs, each executing later steps and consuming usage. This journey should resolve one user per signup. An empty list ends a fan-out; a list retained in one run can still reach the next step.

For Send Email, confirm its recipient path is one contact, its marketing/topic eligibility, its sender and a representative render. Its Then branch follows provider acceptance; its optional email-event branch starts new runs when the selected activities occur.

After publication, inspect the first qualifying examples in Runs. Compare Received and Produced values for Query, the If/Else path and the email activity. Run history tells you where a journey waited or failed. Keep initial enrollment narrow while validating the journey.

Measure the intended result separately: did emailed users subsequently create their own first project? Email delivery and clicks are useful diagnostics, but they do not establish that activation happened or that the message caused it.

Good to know

Existing runs keep their published steps and email templates. Ordinary record values are read as needed. Background Scheduled evaluated attributes use the generation pinned for the root run and its children; evaluated attributes are on-demand lookups. Sending permission, consent and credits are still checked during execution.
Standard internal workflow steps have no fixed operation fee. Compiling the count condition avoids interpreting that condition with AI on every run; the AI guidance step, data work and the email allowance remain separate. Adaptyle would add model usage if you also include it in the email. Review workflow billing before increasing enrollment.

What you cannot undo

Pause prevents new runs and parks existing execution before more steps start. It cannot undo completed writes or an email or HTTP request already in flight. Stop new runs stops enrollment while existing runs continue. Terminate run ends a selected run, its children and pending continuations. There is no skip or rewind control, and accepted effects remain.

A correction affects new runs after publication. Old runs retain their old version, and publishing also resumes the workflow. Review those waiting runs before publishing a correction; do not assume they will inherit it.

Credit shortage, capacity limits and temporary service waits can resume automatically. A terminal failure needs investigation. Inspect an external call or uncertain email acceptance before re-triggering the journey, because the other system may already have acted.

Send a broadcast: a one-time email instead of an automation.
Work with maxinja: the assistant builds and edits a workflow from a description.
Workflow blocks: the fields and behavior of each step.