User Story: No-Code Automations

A No-Code Automation is the event-to-action mechanism. A FLOW is a guided sequence of steps a Contact or Staff member completes; Automations can run after eligible FLOW steps or after the FLOW as a whole. A Generator is a prepared item or structure—such as a Project, Invoice, Folder, Document, Deal, or Follow-up—that an Automation can apply or trigger. An Auto-Template is a reusable package of Automations that can be assigned or triggered where the platform offers it. A Schedule is a date-based way to time Automation sets around a Based-On Date.

These tools can work together, but they answer different questions. Use a FLOW when a person must complete a guided interaction. With the PLUS Bundle, a configured FLOW Cannon can email a link to a published FLOW for completion without a Portal login; link expiration and password protection are optional. Use a Generator when the result should be a preconfigured business item. Use a Schedule when timing should be calculated around a date. A Day Counter can also be used as a condition in an EVERY-trigger Automation, for example to create a follow-up for clients whose last check-in was more than 90 days ago. Passing time alone is not a field-change trigger. Use No-Code Automations to connect the event to the configured outcome.

An Automation can invite a Contact, add a Circle, generate an Invoice, create a Project, apply a Folder Generator, or assign an On-Demand FLOW. It does not make every subsequent resource visible by itself. Portal access, Project participation, Files, billing, LMS access, Communities, and other connected experiences retain their own configuration and assignment rules. Design the action chain together with those destination settings rather than assuming an Automation bypasses them.

A CRM Target is the Contact or Company that the Automation is acting on. CRM-target actions can send a message to that Target, modify CRM information, add or remove a Circle or Audience, apply a Generator, create sales activity, or produce another supported outcome for the Contact or Company. When a workflow involves a Company, confirm whether the action is meant for the Company or the individual Contact before configuring imports, Forms, Automations, and connected work.

A Staff Target is a Staff member receiving an Automation outcome. Staff actions are deliberately different from CRM actions. The Staff menu can include actions such as sending an email or SMS to the Target, adding or removing Teams, setting Staff Custom Fields, assigning an On-Demand FLOW, applying selected generated work, managing LMS access, firing Form Cannons, updating Checklists or Community membership, and triggering an Auto-Template where the pane provides it.

The trigger is the documented state or event that starts the chain. An action is one configured outcome in that chain. A chain is the ordered set of actions saved for that trigger. Required details are the information the action needs before it can be saved—for example, the recipients and content of an email, a selected Follow-up Generator, a Project Generator, a document title and Generator, or the values to write to a Custom Field.

An Automation begins only when its own trigger occurs. A Project or Phase chain runs when the item is set to Completed—whether that status was set manually or by another configured Automation. A Project can also be configured to become Completed when all of its Tasks are marked complete; if that changes the Project’s status to Completed, the Project completion chain can then run.

The same principle applies to Office items. An Invoice’s paid chain runs only once it is completely paid, whether the payment was made by the Client or recorded as paid by Staff; a partial payment does not run that chain. An Estimate chain runs when the Estimate is converted to an Invoice. A Proposal has distinct approval and rejection chains. A generated Invoice or Document can inherit Automations that were configured on its Generator, and the generated item later follows its own documented completion condition.

After the trigger supplies its context, the configuration modal presents the actions appropriate for that target and source. A CRM workflow can work with the Contact or Company that caused the event. A Staff workflow can work with a Staff member. An action can also have its own internal recipient choice: for example, Email Internal(s) can select Staff or Teams and can include a Target’s Coordinator and/or Salesperson; Email External(s) selects Contacts or Circles and is not the action for the assigned user of the item.

Do not substitute one target category for another based on a similar label. Choose the path that exposes the intended target and validate the resulting recipient or record after testing.

Chaining lets one event create several results, but the chain should be reviewed as an operational sequence. A sales-stage transition might send an internal update, create a Follow-up, and create a new Deal or move an existing one. A paid Invoice might generate a document, update a Custom Field, add a Circle, or send a message. A Project completion may change a status or start a prepared follow-up process.

Generated work and changed data remain subject to their own configuration. If the workflow creates a Project, Invoice, Folder structure, Document, Deal, or FLOW assignment, inspect its title, target, status, dates, recipients, assignments, visibility, and downstream Automations before using the pattern broadly.

Deal Automations are assigned from CRM > Deals and are tied to a Deal moving from one Stage to another. Use the Deal-stage chain when the business decision is represented by the sales pipeline. Do not place a sales-stage action on an unrelated Contact or Project event and expect it to receive the same Deal context.

Project and Phase Automations run when their respective record reaches Completed status. That can happen by a direct change or because a configured Automation changes the status. For Project work, the communication and document actions offer Project placeholders, and Task Automations can also offer Task placeholders; the placeholder list supplied by that editor is the list that will resolve for that context. The Apply Task Template action can apply to the Current Project and is the default option when the context supplies that Project.

Use the event appropriate to the commercial state. Invoice paid means fully paid, not partially paid. Estimates trigger on conversion to Invoice. Proposals can be configured separately for Approved and Rejected outcomes; an approved Proposal can use Convert to Invoice with its documented Invoice title, relative due date, gateway, client-notification, redirect, or third-party payment-link choices. A Document Generator can pass its Automations to a generated Document, which then triggers when fully signed.

Estimate conversion and approved Proposal behavior include the documented Convert to Client behavior for a Prospect, which cannot be removed. Review the default notification setting as well as the commercial result before publishing a workflow to live records.

Both Onboarding and On-Demand FLOWs can have Automations after individual Steps and at whole-FLOW completion. The final Step is the exception: its assigned Automations do not run. If a Step with assigned actions is moved to the last position, the available pane is hidden and those actions will not trigger. Put the final outcome in FLOW Complete Automations instead.

A skipped FLOW Step is considered complete, so any configured Step Automation can fire. This is a real alternate path: if an action should happen only after a person actually completes a task, do not attach it to a Step that can be skipped without considering that outcome. When a FLOW is duplicated, its Automations are not duplicated; rebuild or intentionally reapply the needed chain on the new FLOW.

All Kickoff, Update, and General Forms can use Send Email Notification. In a Kickoff Form, Create Contact must be completed before proceeding, and the selected Role determines the optional information that follows; the only other documented Automation there is Send Email Notification. An Update Form exposes the nested No-Code Automation path. A General Form’s documented Automation option is Send Email Notification. Do not assume a Form’s submission gives access to the same full action catalog as a Project, CRM, or FLOW event.

Organization Settings can run Automations when a Prospect or Client confirms an account by logging in to the Portal for the first time. A Schedule, by contrast, times Automation sets around a Based-On Date. The date can be when the Target joins the Schedule, a selected future date, or a Custom Field date. The account chooses CRM Targets or Staff Targets when it creates the Schedule, then adds the Automation details and the timing around that date.

This is the current documented CRM Target inventory. An entry in this list is not a promise that every trigger exposes it; the available pane limits the list to actions valid for the event and target in that location.

Set Custom Field Value can update multiple selected fields. In Project Task or Phase contexts it can also expose Project Custom Fields, and the action can target the Contact’s Salesperson and/or Coordinator when offered. Number fields support documented simple arithmetic with the current value. Date fields can use a specific date, the current date, or documented date calculations. In Invoice and Estimate-related locations, the supported payment or estimate placeholders can be used for relevant calculations.

Before using this action, confirm the field type, the target record, the exact value format, and the consequence of a repeat trigger. If Coordinator and Salesperson are the same person and the chain writes different values to the same field, the later value overrides the earlier one.

This is the current documented Staff Target inventory. As with CRM Targets, only the actions offered in the Automation pane for the current Staff event can be configured.

Use Staff-target Automations when the workflow needs an internal recipient or state change, not when a customer CRM record should receive the outcome. For example, a Staff workflow can assign a Team or Checklist, send an SMS to the Staff Target, or fire a prepared Form Cannon. Check the action’s target, selected recipient, and destination configuration in the Staff context. A completed internal action does not by itself change a client’s CRM Role, Portal access, or connected work.

Schedules allow an account to sequence Automation sets before or after a Based-On Date. The Based-On Date can be the date a Target is added to the Schedule, a specific future date, or the value of a Custom Field. Choose CRM Targets or Staff Targets when creating the Schedule, then configure the date logic and Automations for that target type. This is appropriate when timing, rather than a one-time record event, is the business trigger.

Auto-Templates preserve a prepared set of Automations for reuse in places that offer the Auto-Template option. They can also use documented trigger logic, including restricted target populations, Custom Field conditions, and date-oriented conditions. Reuse is helpful only after the template’s actions, source data, target type, and downstream effects have been reviewed for the new context. An Auto-Template is not a guarantee that every action applies identically across CRM, Staff, Project, or billing workflows.

1. Define the Deal Stage movement that represents the actual qualification or decision point.
2. Configure the stage Automation from CRM > Deals, not from a generic Contact workflow.
3. Add the smallest chain that preserves the handoff: for example, an internal email and a Follow-up Generator for the appropriate Target.
4. If the workflow needs to change commercial status, use the documented Convert to Client action only where the Target is a Prospect and that change is intended.
5. Test the transition with a controlled Deal, then inspect the Deal, Contact or Company, recipient notification, and created Follow-up before using it across the pipeline.

1. Choose the specific Office event: an Estimate converted to an Invoice, a Proposal Approved or Rejected, an Invoice completely paid, or a Document fully signed.
2. Configure the Automation on that Office item or its prepared Generator, and check any built-in conversion behavior before adding custom outcomes.
3. Apply the selected Generator, Document, Project, Folder, follow-up, or communication action only after selecting the correct Target and required fields.
4. For a paid Invoice chain, test full payment and partial payment separately. The paid trigger is for complete payment; partial payment is a different state.
5. Confirm the destination record’s assignments and visibility, not only that an Invoice or Project was generated.

1. Build the FLOW steps a Contact or Staff member must complete and decide which Steps can safely be skipped.
2. Put intermediate outcomes on eligible non-final Steps.
3. Put the final completion outcome in FLOW Complete Automations, rather than relying on the final Step.
4. Review each action when duplicating or revising a FLOW; duplication does not carry its Automations forward.
5. Test completion and skip paths, then verify the resulting assignments, messages, and generated items from the intended Target’s view.

1. Create a CRM Target or Staff Target Schedule.
2. Choose a Based-On Date that represents the intended anchor: entry to the Schedule, a fixed future date, or a Custom Field date.
3. Configure the Automation timing before or after that date and build the permitted action chain.
4. Add a controlled Target and verify the date basis and resulting target type before applying the Schedule to a larger group.

Yes. The configuration modal supports a chain: add an action, complete its required details, then continue adding actions before saving. Review the saved summary and test the full sequence with a controlled record.

The available actions depend on the feature, event, and target type that supplied the trigger. A CRM Target chain and a Staff Target chain are different action sets, and some actions are limited to particular features such as Forms, Proposals, Projects, or Office records.

No. The paid Automation runs when the Invoice is completely paid. It does not run after a partial payment. Record a controlled full and partial payment when validating a workflow that depends on payment state.

Check whether that Step became the final Step. Automations assigned to a final FLOW Step do not execute; use FLOW Complete Automations for the last outcome. Also check whether the intended action was placed on an eligible Step and whether the test followed the actual completion or skip path.

No. A FLOW is the guided experience a Contact or Staff member completes. No-Code Automations are configured commands that can react to eligible FLOW completion events as well as many other SuiteDash events.

Yes, the Send Portal Access Invitation Email action is documented for Contacts in Not Invited status. The invitation action is not a substitute for ensuring the Contact has the appropriate Role and that connected Portal and tool access are configured correctly.