If you're reading this, then you already know there's a lot you can do with Zapier. But there's also a lot your team can do with Zapier. Whether you lead an agency, run a department, or manage your own business, understanding the mechanics of your automations and creating mindful workflows will scale your team's success.
As the co-founder of Xray.Tech, my work involves designing low-code automations to help knowledge workers create more space for meaningful work. Today, I want to share some of the strategies we use to manage thousands of automations and dozens of workflows for companies large and small.
We'll look at every stage of designing and building a workflow that contributes to a great delivery process. We'll cover different techniques for building Zaps for teams instead of just individuals. And finally, we'll talk about the crucial documentation that lets your clients pick up where you left off.
This post was developed from a session given by Tom Nassr at ZapConnect 2022, Zapier's annual user conference. Watch the full session in the video below.
Designing an automated workflow
A successful delivery begins with good design. If the Zap you've built doesn't solve a problem for your client, they'll struggle to adapt it. So how do you craft a well-designed workflow? It starts with understanding the current process you're going to automate.
Zapier is the leader in workflow automation—integrating with 6,000+ apps from partners like Google, Salesforce, and Microsoft. Use interfaces, data tables, and logic to build secure, automated systems for your business-critical workflows across your organization's technology stack. Learn more.
Kick off any project by working with your client to articulate the following points:
Workflow owner: Who will use the workflow and benefit from it? Their perspective will be crucial.
Completion: How do you know when the workflow is finished?
Data: What are the relevant data that make up the automation? What information is required, and where does it come from?
Notifications: Who needs to be notified about this task, and when? Consider fringe cases: when something goes wrong, who needs to be aware of the issue?
Decisions: Which decisions need to be made and by whom? Remember, decisions will often represent different paths that you'll need to build in different Zaps. It's ok to have multiple Zaps for multiple decision paths.
Software: Which apps are used, and are all those apps used correctly? Google Sheets isn't always the answer.
With these clarifications, you'll be able to identify what can be automated. Be sure to check Zapier for all available integrations! With thousands of apps in their app library, the odds are you'll be able to find the one you're looking for.
But don't just ask what you can automate—ask what you should automate. At XRay, we believe people should spend most of their time on work that requires human ingenuity.
We use the acronym C.A.S.T. to describe this work because it requires them to be creative, analytical, strategic, or thoughtful. The more your Zap can automate robotic work and promote C.A.S.T. work, the more content your client will be using the workflow.
Let's take a moment to address the practical aspects of creating a design document. In automation, your design shouldn't be a mockup of a UI or a Figma file. Instead, I recommend using a Business Process Model Notation (BPMN) diagram.
A BPMN lets you map out an entire workflow consisting of several Zaps. This becomes useful in documentation to demonstrate your progress over time. It's also a centralizing document to ensure you include all the people, software, data, and decisions needed to generate your intended outcomes.
Building workflows for teams
Now that we've covered design, let's prepare to build Zaps for your team rather than just yourself. You'll have to structure your Zaps differently to accommodate more people and data in your workflows.
As you can see from the graphic below, when you build a Zap for one person, all the data is typically found in your trigger step.
By keeping the person constant, everything is pretty simple: All the text, I.D.s, dates, times, and other information is in one app and you need to move it to another. The data goes to one place and, it doesn't need to be dynamic.
But when you're building for a team, those constants become variables.
To build dynamic Zaps, you'll need to establish an operational database where you can store information, perform lookups, or run calculations inside the center.
There are countless options here. At XRay, we use Airtable, but you could also use Storage by Zapier, NocoDB, SQL, and the list goes on. Just don't use a Google Sheet! It's challenging to maintain, and you could run into serious trouble should anything in your automation change later. Use tools designed for storage.
Read more: How to automate Airtable.
Put into practice, here's what you'll do: After your trigger step, add a step for reference to the operational database where you'll retrieve the IDs, values, or assets needed to perform subsequent actions. That sounds abstract, so here's an example of what I mean.
Let's say you're building an automation for an internal company feedback form. A team member fills out the form, and when the Zap triggers, it populates their feedback in an email to the department head. It also sends a confirmation to the person who filled out the form via Slack DM.
There are two key variables here: the department head's email address and the person's Slack ID. With an operational database, you'll use this step to look up those contact channels. This way, the messages will always go to the right people, and you only need one Zap to automate it.
Think of your operational database as the air traffic controller for all your automations. You can see all the data you need to run a Zap in one spot, populate it with dynamic data, and pivot between applications to run your workflows. This is table stakes if you want to build scalable workflows.
How to build a workflow documentation checklist
So, you've built an automation that will relieve a pain point for your client's entire team. How do you get it into their hands and ensure they can use the workflow? Good documentation is a lifesaver in any automation project.
When preparing for a workflow handoff, try to include the following checklist items:
A flowchart
This documents the entire lifespan of the workflow and shows how the automation moves data through apps. By using a BPMN, your flowchart can serve dual functions: it can demonstrate the proper workflow to your clients and serve as a building document for your team.
When your client is looking at your flowchart, there will be three main things they'll want to see:
Software: Show every app involved in the workflow.
Decisions: Document the critical decision points and the resulting paths.
Actions: Document every action taken as part of the workflow. And always distinguish human triggers vs. automated actions.
Again, a BPMN is an internationally recognized system with standardized symbols and markers. So you'll be able to communicate all the different elements within your workflow clearly.
Process pages
This is a written, non-technical guide explaining how, when, and why to use the automation and what the expected outputs are. While flowcharts document the entire system from end to end, process pages focus on user experience.
These docs can help train users new to the process or serve as a refresher. Ideally, you'll include a video walkthrough here as an added benefit to text and images.
Resources
Resources consist of every doc, app, and asset the automation uses. You'll want to ensure that all these resources are shared and compiled in a way that makes it easy for your clients to find them.
Ideally, you also want to link these resources within your flowchart to ensure that your client can debug or update the workflow over time without editing the Zap itself.
Workflow handoff and delivery
We've talked about designing your workflows, building Zaps for teams, and all the valuable documentation that goes along with it. But how do you bring that together in a new, comprehensive package for your clients and your team?
Ultimately, packaging and delivering your work is crucial to capping off a successful engagement. It's not enough to build a Zap, the context of your delivery matters too.
You have a few options here:
You can create video walkthroughs of each workflow, referencing relevant documentation and linking to all the connected resources. You could also review the same information on a live video call, then record the session and call it a day.
If video isn't your thing, you might send an email or document with all your references. This gets the job done but feels a little 2010. Sure, it's a functional way to do the work, but it doesn't take advantage of everything current web tools offer.
XRay has created a third approach: Xray Workflow is a free tool we've developed to make it easier to share automated workflows with others. You can use the platform to organize your Zaps, flowcharts, training docs, and required assets in one place and then share the entire resource as a single URL. This gives everyone on your team the context to run a workflow without switching between tabs, searching for files, or pinging their colleagues with questions.
However you decide to do it, always remember: Delivering a workflow is about designing someone's day! You want to put everything they need for a productive day right at their fingertips. I hope the guidelines I've laid out today will help you design, build, and deliver workflows more successfully to your team and your clients.
Related reading:
