Decision Tables Best Practices - Workflow Automation CoE
Import
·
Oct 24, 2022
·
article
Workflow Automation CoE > Decision Tables > Best Practices
Guidance and practical tips
Application Scope
- Create Decision Tables in a scoped application.
- Use ServiceNow source control integration with Git for versioning, forking and branching of your decisions.
- Application names should not include version as part of the name.
When to use Decisions
- Use Decision Tables when your flow has a condition with nested else-ifs.
- Decision Tables are a way to create if, else-if, else-if, ... else statements in a highly performant way.
- They also decouple the conditional logic from the code (the Flow, Script Include, Business Rule, UI Action, etc), where the decision is an argument, and the value/output of the decision is determined via the decision table.
- With this approach, decisions can change, without re-developing and changing your code (Flow, Script, etc..).
- You may choose to offer business users the ability to change the decision table values and outcomes, without requiring a developer to release modifications to the code.
- They also decouple the conditional logic from the code (the Flow, Script Include, Business Rule, UI Action, etc), where the decision is an argument, and the value/output of the decision is determined via the decision table.
- Use Decision Tables when your logic (decisions) change over time, allowing for your code (Flow, Script, Business Rule, etc) to remain consistent.
Branches
- If the steps following your decision are (mostly) the same, you can uncheck the “Use branches” option and use decision outputs (result columns) as variable input for the subsequent steps. This allows your decisions to be easily extensible.
- If the steps following the decision are decidedly different, use branches.
- Branching is restricted to 10 max.
Decision Inputs
- Consider who is building & maintaining the decision. If the responsible person doesn’t know SN architecture, it’ll be easier to work with simple inputs.
- If you’re using fields from a table in your conditions, add a reference input instead of individual String, Integer, True/False, etc. fields. This way you don’t risk asking for inputs that you can’t supply to the decision.
- You can dot-walk to related records from your reference input, e.g., build a condition on a field from the parent task.
- Alternatively, create separate reference inputs if you want to benefit from the color coding if you have many conditions in the same decision.
- Currency and FX Currency field types are currently (as of Tokyo) not supported for decision conditions.
Center of Excellence Navigation
View original source
https://www.servicenow.com/community/workflow-automation-articles/decision-builder-best-practices-workflow-automation-coe/ta-p/2359978
Lisa Holenstein