Adding Conditional Logic

1. Adding Conditional Logic

3.3 Adding Conditional Logic
LOs: [3c]
Automation becomes more useful when it can make simple decisions. That matters because not every workflow should send the same response to every case, and a process that can follow different paths is often more accurate and more helpful.
As you saw in Unit 2.3, conditions help you decide when a workflow should take one path instead of another. Building on that foundation, this reading focuses on conditional logic, which means rules that tell a workflow what to do when a certain condition is true or false. A common example is an if/then rule: if a form response meets one requirement, then the workflow sends one action; otherwise, it sends a different one.
Conditional logic also helps with data handling. For example, a workflow might check whether a field is empty, whether a value matches a category, or whether a response falls into one group or another. This kind of rule lets you keep the automation simple while still responding differently to different kinds of input.
The source includes an example where a workflow uses a condition to route information differently depending on the response. That real-world pattern is useful in situations such as approving requests, sorting leads, or sending different messages to different users, because the automation can react in a way that matches the situation.
As you read, consider how conditional logic changes a workflow from a single straight path into a process that can respond differently to different inputs?
Attribution
Title | Author | Source | License
PRDV000 Unit Readings | Saylor Academy | https://learn.saylor.org | CC BY 4.0

OUTPUT LICENSE: CC BY 4.0

3.3: Adding Conditional Logic
LOs: [3c]
Not every workflow should follow the same path every time. Conditional logic lets a workflow make different choices based on the information it receives, so the process can respond to real situations instead of treating every case the same way. This matters because many work tasks depend on rules such as priority, category, or status.
As you saw in 3.2, data mapping moves information from one app to another. Conditional logic adds a decision point to that movement. If a value meets a condition, the workflow can take one action; if not, it can take a different action. In this way, conditions help you build automations that are more flexible and more useful.
A condition often uses an if/then pattern. This means that if a record meets a rule, the workflow performs one action; otherwise, it may perform another action or stop. For example, if a support request is marked urgent, the workflow can send it to a different queue. If it is routine, the workflow can follow the standard path.
Use conditions to separate different cases: Not all data should trigger the same response.
Example: A form response marked "high priority" creates an urgent task, while other responses go into a regular list.
Best Use: When a process has clear categories or decision rules.
Limitation: Too many branches can make a workflow hard to follow.
Keep the rule simple and clear: The platform must be able to test the condition without confusion.
Example: "If status equals approved" is easier to manage than a long, unclear rule.
Best Use: When you are adding your first logic branch.
Limitation: A rule that is too narrow may miss valid cases.
Use a fallback path: A workflow should still behave safely when the condition is not met.
Example: If a request is not urgent, it can still be assigned to the normal review path.
Best Use: When you want the workflow to handle both expected and unexpected inputs.
Limitation: A weak fallback path may hide problems instead of solving them.
A practical example is an intake form that sorts requests into different folders based on category. If a person selects billing, the automation sends the request to one team; if they select technical support, it sends the request to another team. That simple branching rule helps the right person see the right request sooner.
Job-ready Tip: Write the rule in plain language first
Before you build the condition in the platform, write the rule as a sentence. If you cannot explain the rule clearly, you may need to simplify the workflow before you automate it.
As you read this subunit, ask yourself how conditional logic can make a workflow more accurate, and where a simple fallback path would improve the process.
Sources / Further reading
(Authored by Saylor Academy, CC BY 4.0)
Estimated reading time: 5 minutes
3.3: Adding Conditional Logic
This reading supports Unit Learning Outcome 3c.
When you build a workflow, you rarely want every item to follow the same path. Conditional logic lets you make a workflow ask a yes-or-no question and then choose what to do next based on the answer. This matters because real work often depends on small differences in the data, such as whether a field is empty, whether a file meets a rule, or whether a request needs special handling.
As you saw in Unit 3.2 when you connected applications and moved data, a workflow can pass information from one step to the next. Conditional logic adds a decision layer to that data flow, so the workflow can treat different records in different ways. In other words, data handling moves the information, and conditional logic decides how to use it.
What conditional logic does
A condition checks whether something is true or false. If the condition is true, the workflow follows one action. If it is false, the workflow follows a different action.
Check for a value
Example: If an order has a shipping address, continue to the delivery step.
Best Use: Use this when a later action needs complete data.
Limitation: A workflow can still fail if the value exists but is not correct.
Route by category
Example: If a support request is marked "billing," send it to the finance team; otherwise, send it to general support.
Best Use: Use this when different cases need different responses.
Limitation: Too many branches can make the workflow hard to follow.
Stop or continue
Example: If a form response is missing a required field, stop the workflow and send a correction request.
Best Use: Use this when incomplete data should not move forward.
Limitation: A strict rule can block valid work if the condition is too narrow.
Working with data before you test a condition
Before you apply a condition, you often need to prepare the data. That may mean checking whether a field exists, making text easier to compare, or separating one type of input from another. In a no-code workflow, this preparation helps the condition read the data in a reliable way.
For example, imagine a course registration workflow. If a student submits a form with an email address, the workflow can send a confirmation message. If the email field is blank, the workflow can send the form to a review step instead. The same workflow can also check whether the request came from a new student or a returning student and send each group to a different message or task.
Why simple conditions are powerful
A workflow does not need complex programming to make useful decisions. Even a simple condition can prevent errors, save time, and reduce manual review. The key is to define the rule clearly and keep each branch easy to understand.
Use one condition when one decision is enough.
Use multiple conditions when the workflow must sort records into several groups.
Use a default path when no special case applies.
Job-ready Tip: Keep conditions tied to one decision
When you design a workflow, write each condition as a single clear question. If you need to ask two different questions, split them into separate steps. This makes the workflow easier to test, easier to explain, and easier to fix when the data changes.
As you read this section, consider a workflow you already planned in Unit 2: where would you need a decision point, and what exact data would that decision need in order to route the work correctly?
Sources / Further reading
(Authored by Saylor Academy, CC BY 4.0)
Estimated reading time: 6 minutes
3.3: Adding Conditional Logic (covers 3c, 3d, 3a, 3b)

Callback before_footer in local_aigrade component should be migrated to new hook callback for core\hook\output\before_footer_html_generation
  • line 7225 of /lib/moodlelib.php: call to debugging()
  • line 7292 of /lib/moodlelib.php: call to {closure}()
  • line 71 of /lib/classes/hook/output/before_footer_html_generation.php: call to get_plugins_with_function()
  • line 987 of /lib/classes/output/core_renderer.php: call to core\hook\output\before_footer_html_generation->process_legacy_callbacks()
  • line 97 of /mod/book/tool/print/index.php: call to core\output\core_renderer->footer()