Workflows

Automate project follow-ups with recipes you adjust, test and turn on.

Workflows take repetitive follow-up off your plate. Each workflow waits for one thing to happen in a project, such as a client submitting a form, and then does a short list of steps: email someone, post a message in the portal, chase a task, move a task forward. The quickest way to build one is to start from a recipe, adjust it to the project, run a test, and turn it on. This page walks through that, then explains each trigger and step and how runs work.

How workflows work

• One trigger, then steps: a workflow starts from exactly one trigger and runs its steps top to bottom. To react to two different things, make two workflows; each stays short and easy to read.
• On or Off: a new workflow is Off. It does nothing until you turn it on with the switch in the builder header or on the workflows list. A workflow with unfinished steps can’t be turned on: the switch takes you to the first step that needs finishing instead. Turning a workflow off cancels its runs in progress right away, and each run says “The workflow was turned off, so this run stopped.” They don’t resume when you turn it back on.
• Project scope: a workflow belongs to one project and only touches that project’s tasks, stages and people. Workflows copied from a template show which template they came from; changes you make stay in the project.
• Roles instead of names: steps can point at “the task that started this workflow”, “the project lead” or “the client who did it” instead of a fixed task or person. Roles are filled in when the step runs, so the workflow keeps working when people or tasks change. In a project, the builder shows who each role is today next to it. See Roles.
• Only if: any step except a wait can carry one condition, such as “only if that task is still In review”. When the condition is false, the step is skipped, the run shows why, and the run carries on.
• Retries: when a step fails for a temporary reason, such as the email provider being briefly unavailable, Upclient retries it a few times with a growing pause. If it still fails, or retrying can’t help (for example a role nobody holds), the run stops with the reason in plain words and a link to fix it, and the person who created the workflow gets an in-app notification (at most one per workflow per day; workspace Owners get it when the creator has left). Turn these alerts off under Account → Notifications → Workflows.
• Runs: every time a workflow fires, Upclient records a run that says why it started and what each step did. The same change never triggers a workflow twice, and changes made before the workflow was turned on don’t trigger it. See How to review runs.
• Marked as automated: portal messages a workflow posts show Automated by and the workflow’s name in the conversation, and changes a workflow makes to a task (status, assignees, emails it sent about the task) appear in the task’s Activity as Workflow, with a link to the run. They aren’t credited to the person whose action started the workflow.
• Loops: when workflows keep triggering each other, Upclient cancels the run after five workflows in a row with the reason “Stopped to prevent a loop”. This also counts chains that pass through a date-based trigger, such as a workflow that moves a task back to Active and another that acts when a task has been Active for a day.
• One message per client per event: when two workflows react to the same event and both message the same client on the same channel (email, or the portal), only the first one is sent. This also counts a client’s email address typed into a step by hand. If the first workflow hasn’t sent yet, the later step waits a minute and checks again. The later step is Skipped with “Already sent by” and the other workflow’s name, and the run carries on. Steps in the same workflow don’t block each other. Saving or turning on a workflow warns you when another workflow that’s on already messages the client on the same event.
• Client email settings: reminder-type emails respect a client who turned off task emails in the portal: the Send a task reminder step, and Send an email steps in workflows started by Task overdue, Task due date, Task status elapsed or Client hasn’t signed in. The run shows who was left out and why, and the step is Skipped when nobody is left. Other emails, such as a thank-you for a signed contract, always send.
• Hourly limits: each workspace can start up to 500 workflow runs and send up to 200 workflow messages to clients (emails, portal messages and reminders) an hour. Past a limit, nothing is lost: new runs, or the client-facing step a run is on, wait and carry on when the hour is up, and they show Paused: limit reached on the workflows list and in the run. Workspace Owners get one in-app notification per limit per hour. Contact support if your workspace needs higher limits.
• Time zone and working hours: date-based triggers and Wait until dates use the project’s time zone, or the workspace time zone if the project doesn’t set one, or UTC. Change it in Project Settings. Working-day waits and Then continue at follow your workspace’s working days and hours, in the workspace time zone, from Workspace Settings.

How to create a workflow from a recipe

1. Open a project and select Workflows. A project without workflows shows the recipes straight away; otherwise click New workflow (or press C).
2. Under What should happen automatically?, pick the recipe closest to what you want. Upclient creates the workflow, Off, and opens it in the builder. Start from scratch creates an empty one called “Untitled workflow” instead.
3. Read In plain words at the top. It describes the whole workflow in one or two sentences, with the people each role stands for today.
4. Adjust it. Click the trigger or any step to change it in the panel on the right (on a phone or narrow window, the panel opens as a sheet). Use + between steps or Add step at the end to add a step, drag a step by its handle (or press Alt+↑ / Alt+↓ on a selected step) to reorder, and use ⋯ → Remove step to remove one. Removing shows Undo for a few seconds.
5. Finish anything marked in amber. Unfinished steps have an amber marker, and a banner above the steps lists what’s missing with a link to the first one.
6. Click Save changes (or press ⌘S / Ctrl+S). Leaving with unsaved changes asks first.
7. Click Test run to see what would happen (see Test run). Nothing is sent.
8. Turn the switch to On. The workflow now listens for its trigger.

You can rename a workflow from the name in the header. ⋯ → Duplicate in the builder, or Duplicate in a row’s menu on the workflows list, makes a copy called “… copy” that starts Off.

Recipes

Recipes use roles, so they work in any project without picking people. Narrow the trigger to a particular task or stage if only one should start the workflow.

Test run

Test run in the builder header shows, step by step, what the workflow would do with the unsaved version you’re looking at. Nothing is sent, posted or changed.

• Try it with: pick something that really happened in the project and matches the trigger, such as a form a client submitted last week, or A made-up example with this project’s people. If nothing matching has happened yet, the made-up example is used.
• Each step reads as a sentence, such as “Would email Priya Natarajan (project lead)” or “Would message Maya Okafor in the discussion on ‘Brand questionnaire’”, with the subject and message filled in.
• Waits show when the run would continue. Steps after a wait that have an Only if condition show “Would be decided then”, because the condition is checked when the run gets there.
• A step that couldn’t run shows why, such as “This project has no primary contact”, with a Fix step link.
• See the email opens the email as the recipient would get it, with real names, links and your workspace branding. Preview with real data in an email step’s panel does the same.

Triggers

For form, contract and upload triggers you can pick On which task; leave it on any task to react to all of them. Project created is only offered in project templates, because a project workflow is added after the project exists. Workflows created earlier with Task created, Stage created, Add to portal or Remove from portal keep running and can still be edited, but these aren’t offered for new workflows.

How date-based triggers are timed

Project and task dates are calendar days, so date-based triggers count from the start of that day (midnight) in the project’s time zone:

• An offset in days or weeks fires at midnight on the resulting day. For example, “1 day before” a task due on March 12 fires at 00:00 on March 11.
• An offset in hours counts from midnight on the date. For example, “2 hours before” a task due on March 12 fires at 22:00 on March 11.
• Task status elapsed counts from the moment the task entered the status, not from midnight.
• Task overdue fires at midnight at the start of the day that is the set number of days after the due date.

Date-based triggers are checked every 15 minutes, so a workflow runs within 15 minutes of its moment.

Steps

The Add step menu groups steps by who they’re for.

Waits sit between steps on the timeline with a clock marker and aren’t numbered, so “Step 3” always means the third thing the workflow does.

How the Send an email step works

• To: choose roles (see Roles), named people on the project, and/or Other email addresses. Roles pick whoever holds them when the email is sent.
• Subject and message: both are required. Use Insert field (or type @) to add merge fields.
• Greeting: every email starts with “Hi” and the recipient’s first name. If the message begins with a greeting line of its own, such as “Hi Maya,”, it’s left out so the email doesn’t greet twice.
• Merge fields: {{client.firstName}}, {{client.name}}, {{client.email}}, {{company.name}}, {{project.name}}, {{task.name}}, {{task.link}}, {{task.dueDate}}, {{stage.name}}, {{lead.name}} and {{workspace.name}}. Client fields use the client receiving the email, otherwise the client who did it, otherwise the primary contact. Task link opens the task in the portal for clients and in Upclient for your team. A field that doesn’t exist, such as {{client.nickname}}, is marked on the step and stops the workflow from being turned on.
• Sender: emails to clients come from your workspace name followed by “via Upclient”, and client replies go to the project owner. See Client Portal.

How the Send a portal message step works

• To: client roles or named clients. Only clients with portal access to the project receive it; anyone without access is left out.
• Post in: The task’s discussion (everyone on the task sees it, and the recipients are mentioned) or A new conversation with a subject, visible only to the recipients and the team.
• Send as: the project lead or a named teammate. The message appears from them, and client replies go back to them.
• Message: sent exactly as written, as plain text with merge fields filled in. No greeting is added, so start with Hi {{client.firstName}}, if you want one.
• A run never posts the same message twice, even if the step is retried.

How the Send a task reminder step works

The step sends the same reminder as Remind on the task. If there’s nothing to remind about when the step runs, for example the task is already completed or in review, the step is marked Skipped with the reason and the run carries on. If the reminder can’t be sent for a reason you can fix, such as no client assigned or no portal access, the run stops with that reason.

What Set task status leaves alone

A workflow never sets a task back. Setting a task to Active only opens a Draft; a task that’s already In review, Completed or Archived is left as it is. Each skipped step is marked Skipped with the reason, for example “The task is already Completed, so it was not moved back to Active.”, and the run carries on. Tasks in an archived project or an archived stage are never changed, and a task whose contract isn’t signed yet is never marked Completed by a workflow.

Roles

Steps that act on a task or a person can use a role instead of a fixed choice.

Tasks (Set task status, Assign a task, Send a task reminder, Wait until a task status, portal messages in a task’s discussion, and conditions):

• The task that started this workflow: the task in the trigger, for example the task whose form was submitted. Only offered when the trigger is about a task.
• The next task in the same stage: the task after it in the stage’s order. If it’s the last task in its stage, the step fails with “… is the last task in its stage, so there is no next task.”
• A specific task: any task in the project.

People:

• The client who did it: the client who submitted the form, signed or uploaded. Only offered for those triggers.
• All client contacts on the project and The client’s primary contact.
• Project lead: the project’s owner when the step runs.
• Everyone assigned to the task: the assignees of the task that started the workflow.
• A named person on the project, and for email only, a fixed email address.

If a role is empty when the step runs, for example the project has no primary contact, the step fails straight away with a reason such as “This project has no primary contact, so there was nobody to send this to.” It isn’t retried. Add the person and the next run works.

Only if

Turn on Only if at the bottom of a step to give it one condition: a task (a role or a specific task), is still or is not, and a status. The condition is checked when the run reaches the step. When it’s false, the step is marked Skipped with the reason, for example “Homepage copy” is Completed, not In review, and the run moves on.

How waits are timed

• Minutes and hours are exact.
• Days keep the same time of day, also across daylight-saving changes.
• Working days skip the days your workspace doesn’t work. A wait that starts outside working hours counts from the next working morning. For example, 2 working days from Thursday 14:30 continues on Monday at 14:30.
• Then continue at sets the time of day the run continues, such as 9:00 AM. If that falls on a day off, the run continues at that time on the next working day.

How to manage workflows

• The Workflows list shows each workflow’s trigger in a sentence, when it last ran and how that went, and where it came from. Search by name or trigger, and filter to On or Off.
• Use the switch on a row to turn a workflow on or off without opening it. An unfinished workflow opens in the builder at the step that needs finishing. Turning off a workflow with runs in progress asks first and tells you how many runs it cancels.
• A row’s ⋯ menu opens, duplicates or deletes the workflow. Deleting also deletes its run history; the confirmation says how many runs that is.
• The Settings tab of a workflow lets you rename it, lists anything unfinished, shows where it came from and when it was created and last changed, and has Delete workflow.
• If someone else saved the workflow while you were editing it, your save is refused with a Reload option, so neither of you overwrites the other’s changes without noticing.

How to review runs

Open a workflow and select Runs, or See runs under In plain words. The list shows each run with when it started, its status and why it started. Use All, Waiting, Failed and Finished to narrow it down, and Show older runs to go further back. Select a run to open it; on a phone the run opens on its own screen, and All runs takes you back to the list.

A run reads top to bottom:

• Status: Waiting (paused on a wait or a step that will run later), Running, Paused: limit reached (with the time it carries on), Finished, Cancelled, or Stopped at step 3 when a step failed. Under it: how many steps are done and how long the run took.
• Started because: what happened, in words, such as “Maya Okafor submitted Website content questionnaire on “Share your project brief”.” When the event didn’t record who did it, Upclient looks it up from the submission, upload or signature.
• Each step: finished steps are written in the past tense with the people they actually reached and their role, such as “Emailed Elena Marsh (project lead)”, the time and how long the step took. An email step has see the email, which opens the email exactly as it was sent; a portal message has see the message, which opens the conversation.
• Waiting steps: “Waiting until Tue, Nov 17, 9:00 AM” in the project’s time zone, with the reason, such as “2 working days, skipping the weekend, then at 9:00 AM”.
• Skipped steps: the reason, such as “Skipped: “Homepage copy” is Completed, not In review.”, “Skipped: Already sent by “Brief received”.”, “Skipped: Maya Okafor turned off task emails in the portal.” or “Skipped by Alice Moreno”. When only some people were left out, the step lists them, such as “Not sent to Daniel Reyes: turned off task emails”.
• Steps not reached yet: what they will do, who that is today, and any Only if condition.
• Cancelled runs: who or what cancelled them, such as “Cancelled by Alice Moreno.” or “The workflow was turned off, so this run stopped.”
• Failed runs: the problem in plain words, such as “Nobody is assigned to the task, so there was nobody to send this to.”, and a button to fix it: Assign someone to the task, Set the project lead, Open portal access, Edit the workflow and so on.

How to act on a run

Only the step the run is on can be changed, and only by workspace Owners and Admins.

• Continue now ends a wait early. The step then reads “Continued early by” and your name.
• Send now sends an email, message or reminder step right away. When the step reaches a client, Upclient asks first.
• Run now runs any other waiting step, and Skip moves on to the next step; the step reads “Skipped by” and your name.
• Cancel run stops the run after asking. Anything already sent stays sent, and the run reads “Cancelled by” and your name.
• Retry from step 3 on a failed run starts it again from the failed step, with a fresh set of retries, after you fix the problem. Steps that already ran aren’t repeated, and an email or message that already went out isn’t sent twice. When the failed step reaches a client, Upclient asks first. The workflow has to be on.

A finished or cancelled run can’t be started again. Fix the workflow and it applies to the next trigger.

Finished runs are kept for 90 days, then deleted with their timelines. Runs still waiting or in progress are kept until they finish.

Workflows in project templates

You can also add workflows to a project template from the template’s Workflows tab, starting from the same recipes. When you create a project from the template, its workflows are copied into the new project, with tasks and stages pointing at the project’s copies.

• The switch in a template workflow reads On in new projects or Off in new projects: it decides whether each copy starts on. Turning it off doesn’t touch projects that already exist; each has its own copy. The meta line under In plain words says how many projects are running a copy.
• Library templates come with their workflows on: opening the next tasks when the agreement is signed, Brief received for the questionnaire, starting the next stage with a note to the client, and Chase an overdue task. A workflow that emails the primary contact starts off when the project has no primary contact yet; turn it on once you’ve set one.
• Template workflows use roles, because templates have no clients and only a default team. Each copy keeps the roles and fills them in from its project when a step runs.
• Test run in a template uses sample data (a made-up client called Sam Rivera at Harbor & Pine), or pick a project made from the template to use its real people and tasks.
• A template workflow has Builder and Settings tabs. Runs happen in projects, so look at the copy in a project to see them.

Best practices

• Start from a recipe, even when you’ll change most of it: it comes with sensible roles, waits and wording.
• Give each workflow one job and a name that says what it does.
• Run Test run with something that really happened before turning a workflow on.
• Prefer roles over named tasks and people, so the workflow survives changes and copies cleanly into templates.
• Avoid workflows that undo each other, such as one that completes a task and another that reopens it when it completes.
• Space reminders a few days apart so clients have time to act.
• Check Runs after turning on a new workflow to confirm it behaves as expected.