Documenting processes is great in theory, but creating and following them can be a pain.
Your processes need to be standardized so that everyone’s performing the same tasks consistently. However, that often leaves you with either a large, complex and unusable process which covers every situation or lots of smaller, specialized processes which become difficult to manage or track.
Conditional logic saves you all of that trouble by letting you create processes which change to suit the situation at hand.
By setting rules for your processes to follow and update based on their outcome, you can simplify your processes and make even the most complicated task list easy to navigate. All optional tasks can be automatically hidden from view until (and if) they are required to keep your dashboard clear and encourage teams to avoid taking shortcuts.
Nobody wants to work through a horribly complex process that you know you won’t need half of to complete your task.
However, as with business process automation, conditional logic’s power is best shown through examples, so today I’ll be showing you both how to use it and giving eight example processes which take advantage of it, including client onboarding and user support.
How to use conditional logic
Conditional logic is the idea that you can set rules which cause your processes to change. This means that you’re no longer always using and viewing the same process, but rather an intelligently designed workflow that only shows you what you need to see.
Think of it as an “if this happens, show or hide these tasks” model. The details and use cases differ, but all rules check to see whether their conditions have been met and result in tasks in your checklists being shown or hidden from view.
The ways this can help you in your regular process management (and thus every other aspect of your business) are many, but they mainly include:
- Letting you create a single dynamic process instead of several specialized ones
- Having processes automatically adapt to present instructions and tasks based on your specific needs
- Hiding irrelevant tasks to keep things tidy
- Making processes easy to start by limiting the initial task view, thus keeping motivation high
Process Street implements conditional logic by letting you set rules within the templates you use to document your workflows. The checklists you run from these templates then follow those rules and update based on the actions you take when working through them.
For example, if you’re working through a client onboarding process and show that your particular client wants to have a logo designed, the checklist would update to show you the tasks for designing a logo.
To set these conditional logic rules you’ll need to log into (or sign up for) a Process Street account and then choose the template you want to set rules for. Then, go into the template editor and click the “Conditional Logic” button towards the top of your dashboard.
From here you can hide tasks by default and create rules to show or hide tasks depending on what’s entered into form fields when working through the checklist. The fields you can draw from are:
- Short Text
- Long Text
- Multi Choice
The conditions you can set for those fields are:
- Is not
- Has no value
- Has any value
- Starts with (Only text fields)
- Ends with (Only text fields)
- Contains (Only text and Multi Choice fields)
- Does not contain (Only text and Multi Choice fields)
In other words, you could have a rule saying “if this multi choice form field contains X, show or hide task(s) Y”. If you’re still not quite sure of what the concept is all about or how to use it, check out our help site article on conditional logic.
While this might seem unimpressive at a glance, the power of this feature comes in the ways you can use it, so let’s get stuck right in with eight examples of using conditional logic.
8 examples of conditional logic
Before we get stuck into the examples I’d like to highlight that some of these will have premade templates embedded into them. These can be imported directly into your Process Street account free of charge and used straight away or edited to suit your needs.
However, due to the public version being locked (you need to have them in Process Street for your changes to save), conditional logic is not applied in the preview. To test out conditional logic in these examples for yourself, log into Process Street and import them into your organization!
1. Customizing the hiring process for each department
Without conditional logic there are two options for documenting your hiring processes. The first is that you could create a separate process for every department. This would let you record detailed instructions for every position, but managing, reviewing, and tracking your hiring as a whole would become awkward.
Alternatively, you could have one massive hiring process with separate sections for the tasks involving employees for each department. For example, a marketing section would include a step to review their marketing portfolio, and the development section would include a prompt to host a development interview.
The problem here is that showing all tasks for every hire means that you’re throwing a lot of irrelevant work at your employees, which is likely to slow them down, sap their motivation, and even cause them to take shortcuts to avoid doing everything.
Conditional logic solves this by letting you have one large hiring process for all departments, but then hiding tasks which aren’t relevant to the checklist you’re currently working through. So, marketing tasks are shown for marketing candidates, development tasks for development candidates, and so on.
This is done by hiding all department-specific tasks by default. Then there could be a dropdown form field early in the checklist to let the person working through it select the type of candidate they’re hiring. A rule is then set to show a set of tasks relevant to the drop-down choice.
In other words:
- Hide all tasks apart from “Contact the candidate” so that the view isn’t cluttered with irrelevant content
- If the “What department are we interviewing for” dropdown field is set to “Marketing”, show the “Review marketing portfolio” task
- If it’s instead set to “Development”, show the “Conduct development interview”, and the same for “General” with showing the “general interview” task
- For all three of these departments, two rules exist to show either the employee onboarding tasks or one for giving a declined email to the candidate, depending on whether they were marked as passing the interview
2. Promoting your content to the sources you’ve drawn from (if you know them)
It’s easy to segment your processes for conditional logic when using form fields such as dropdowns which have set outcomes. When the form field is less predictable your rules become harder to set.
Short text form fields are usually reserved for snippets of information that don’t fit a set formula. For example, you might fill one out with a contact’s name or that of their company. You can’t predict what name will be entered, so the field needs to leave a space for typing, rather than giving set outcomes.
Conditional logic, however, still works in this situation. You just need to be a little more thoughtful about how you use it.
Let’s say you’re promoting a piece of content. One of the best ways to do this is to try and get other people to share it on social media. To do that, it’s a good idea to quote or otherwise link back to them in that content. Do that and they’ll be more inclined to share that post with their own audience.
By including a short text field to record the name of anybody you mention in your post, you can use that as a trigger to show the tasks for reaching out to that source and asking them to promote it. If you don’t mention any sources, the form field is left blank, and the tasks to follow up with them remain hidden.
The conditional logic rule for this would be that if your short text field “contains any value” Process Street can show the tasks for pitching it directly to that source. That way:
- If any of the “Source Mentioned” short text form fields in the “Prepare your post” task are filled with an answer, show the “Contact the sources you mentioned” task
3. Changing your client onboarding process based on the options/packages clients select
Another great way to use conditional logic is to customize your client onboarding process to suit the services, package, or duties that your client is looking for. For example, if a client wants you to design a website then you’re going to need to carry out different tasks than to someone just looking for a logo.
The best way to do this would be to include a multi choice form field which would let the person filling in the checklist select the desired elements, packages, or services you offer. Sticking with our design example, this multi choice field could consist of options ranging from website and homepage design to videos, logos, blog images, and more.
Each multi choice option would be set up in your conditional rules to show a relevant task (or group of tasks). Although you would have to create separate rules for each multi choice option, it’s still much more organized than showing every task at once and having to ignore the irrelevant ones.
To keep things simple, the rules could be:
- If “Design Elements” multi choice field contains “Logo”, show “Logo Design” tasks
- If “Design Elements” multi choice field contains “Website”, show “Website Design” tasks
- If “Design Elements” multi choice field contains “Branding”, show “Branding Elements Design” tasks
Again, this lets you customize your process to give instructions for every possible situation without cluttering it up to high heaven. After all, no matter how useful it is, nobody will want to use or follow a process if it appears to be 40 steps long for something that should only take 15.
4. Ensuring projects are updated on all platforms, no matter their source
Process automation is an incredibly powerful tool, but one which can be awkward to use in certain circumstances. This is especially true if you’re transitioning between two pieces of software or two methods of carrying out your tasks.
For example, here at Process Street, we’re changing our content marketing system (including our blog post tracking) from using Trello to Airtable. During the switch many of our processes need to be updated, including the Zaps in Zapier which automate them. This includes our method for logging and categorizing blog post ideas, which I’ll be using in this example.
Our old method was as follows:
- Record a post idea in a new Trello card
- A pre-publish checklist in Process Street is automatically run
- The Trello card’s ID is automatically pushed into a hidden form field in the pre-publish checklist
- That hidden ID is used to automatically post a link back into the Trello card
Now, however, we’re halfway between Trello and Airtable. Trello is still used to sort our blog posts into a calendar view, but all of the information for them is stored in Airtable until we get the calendar running.
Assuming nothing gets forgotten, our new (temporary) method is:
- Record a post idea in Airtable
- Manually run the pre-publish checklist
- Manually create a Trello card to match
- Manually paste links to the pre-publish checklist in the Airtable and Trello entries
Conditional logic solved this problem by taking chance out of the equation and showing a task to remind us to move the idea into Trello when applicable.
Since the hidden form field for the Trello card’s ID will only be filled in if the idea was originally documented in Trello, the conditional log rule for the template can just be as follows:
- If the “Trello Card ID” hidden form field has no value, show the task “Create Trello card for idea”
This way all of our platforms stay up to date despite transitioning between apps.
5. Skipping email prospecting tasks if the address is already known
Searching for the email addresses of leads and contacts can be tedious at the best of times, but it’s important to have a consistent approach to doing it. However, that doesn’t mean that your team wants to see said method even when they already know the email address of their prospect.
It’s useful to have a set method for finding the email address of the leads you’re researching, but your process gets quickly bogged down with useless tasks if you assume that you’ll never know someone’s email address beforehand. It might sound like a fringe case, but these small examples are precisely the ones which break your finely crafted processes and cause a mess in your organization.
As always, conditional logic can help.
By including an email address form field to fill in at the beginning of your prospecting checklist, you can provide a buffer to stop any redundant tasks appearing. If you know the lead’s email address already you can fill in the form field and let conditional logic hide the tasks related to finding it.
Alternatively, if you leave it blank, those tasks will remain in view so that you can follow precise instructions for finding their email.
In other words:
- If “Client Email Address” form field contains any text, hide the “Finding their email address” heading and tasks
Unfortunately, if the initial email address form field is filled in at any point, those tasks will be hidden (even if they’ve been worked through). It’s not a huge issue (they don’t get deleted), but if you’d like to see everything you’ve carried out at once then you just need to put their emails address in another form field instead, such as at the end of the optional tasks.
6. Promoting content with techniques to suit their domain
Trying to promote all content with the same techniques isn’t just idealistic – it’s actively damaging to your marketing efforts as a whole. Techniques used on Facebook don’t necessarily work on Twitter, and content from your own blog can be tackled in very different ways to guest posts on other sites.
So, how do you stay consistent and make sure that the same tasks are being carried out without having to document 15 different templates or have one giant, messy one?
Conditional logic, of course!
First up, to find out how to segment our promotion template we need to know what causes the different tasks to be carried out. In this case, it’s the base domain of the site that the content is on, but not the full URL. This lets us create a handy workaround to let conditional logic work even though the content’s URL is never the same.
This is done by telling Process Street to search our “Content URL” website form field for a certain section of text rather than the whole thing. For example, if the URL contains “www.facebook” then it’s safe to assume that you want to see the tasks for promoting content that’s from Facebook. The same goes for Twitter (www.twitter), your own site (www.insertyoursitehere), and any others you might promote the content of.
- If the “Content URL” website form field contains “www.facebook” then show the tasks for promoting content that’s from Facebook
- Add new rules for other sites (eg, “www.twitter” showing tasks for Twitter content)
7. Blocking meeting checklists until a date has been set
Although you can prevent people from working on tasks by using stop tasks or required fields, there’s an argument to be made for how tidy conditional logic makes everything. Rather than being able to see the tasks you’ve got left to go but not being able to complete them, the tasks are hidden entirely until you reach them.
For example, let’s say that you have a checklist for running a daily standup meeting, and in the first task you have a date form field so that you know exactly when the meeting took place if you go back to it.
To make sure this is filled in, you make the date field a required field and the task containing it a stop task. That way nobody can go further in the checklist without completing that task, but the task can’t be completed without filling in the date field.
This is great for making sure the date is recorded, but it can be distracting to see all of the other tasks hanging there while not being able to work on them.
Conditional logic can prevent this distraction by hiding all tasks that haven’t been unlocked to work on yet.
In this example, we could take the required date form field and create a rule to tell Process Street to hide all subsequent tasks until it has been filled in.
- If the “Meeting Date” date form field has no value (isn’t filled in), then hide all subsequent tasks
8. Tailoring your support process to suit each ticket
Customer support and user stories are also elements which can cause massive problems, even with standardized processes.
Every complaint or help request you receive can be worded differently enough that regular conditional logic isn’t suitable, but you also don’t want to be cluttering up one of your busiest templates with tasks that don’t relate to every checklist. You don’t need to see how to diagnose a technical issue if the customer is just saying hello or testing the support box, so there’s no reason to see the tasks to do so during every checklist.
Instead, you can use a long text form field with conditional logic to divide up your checklists effectively. Zapier can be used to automatically run your support checklist for each ticket you receive, and then push either the ticket’s text or an in-team summary of the ticket into a long text field which you can then search for specific words to use as triggers.
For example, let’s say that you have somebody reading through each ticket and creating a standardized user story for each. This user story is recorded using a long text field in the checklist.
In this case, rules can be set up to search for trigger phrases such as “technical issue” or “feature request”. If detected, the checklist could automatically update to provide instructions for dealing with those kinds of tickets.
While this can be done with the raw message from support tickets too, elements such as spelling and word choice make it much more reliable to use after the tickets have been summarized in a standard user story.
- If the “User Story” long text form field contains the term “simple question”, show the task for processing a simple question
- If it instead contains “technical issue”, show the tasks for processing and dealing with a technical issue
- The same goes for all other types of user story, including “app question”, “feature request”, and so on
Conditional logic is the next step in simplifying your processes
Stop getting lost in complex processes or bogged down with too many simplified ones. Conditional logic is here to help you cater your processes to every situation without compromising your consistent methods or ability to track the results.
Even so, don’t beat yourself up if you fail to predict a way in which your processes need tweaking (either regarding conditional logic or in general). There will inevitably be a new use case which defies your current methodology or process format, but when that time comes just go back into your process and tweak what you need to improve.
Much like with documenting or automating your processes, while creating conditional rules may seem intimidating at first, all it takes is slow, steady progress with your rules to bring massive rewards later down the line.
Have any questions or powerful use cases for conditional logic of your own? Let me know in the comments!
Appreciating the time and energy you put into your website and in depth information you
provide. It’s good to come across a blog every once in a while that isn’t the same old rehashed information. Wonderful read!
I’ve saved your site and I’m adding your RSS feeds to my