# Decision component URL: https://docs.awellhealth.com/docs/design-care-flows/decision-component > For the complete documentation index, see [llms.txt](https://docs.awellhealth.com/llms.txt). Decisions shape how a patient moves through a care flow. The **Decision component** is a node on the canvas that holds those decisions in one table, so the rules are explicit and easy to read. ## Decision components handle your most complex routing logic [#decision-components-handle-your-most-complex-routing-logic] A decision table, with a column per input, one row per rule, and the outcome each rule produces Use conditions on transitions for a single branch and a decision table for more than one. Every condition and outcome sits in one table, visible at a glance rather than traced through a chain of transitions. Changing the logic means editing a row or adding one, instead of rewiring paths where a small mistake causes a subtle wrong turn. Rules stay readable as they grow, while a chain of if-else transitions gets harder to follow with every branch added. The table also documents itself: a clinician or product manager can check the logic without a walkthrough from the person who built it. ## A decision table pairs inputs with the outcome each rule produces [#a-decision-table-pairs-inputs-with-the-outcome-each-rule-produces] The Decision component is a node in the Studio sidebar. Drag it onto the canvas to add one, then open it to build its decision table. The table has a column for each input and a row for each rule: * **Inputs** are the data points the decision reads. Each one is tested with an operator such as equals, greater than, or contains. Studio suggests operators and data points as they are typed. * **Rules** are the rows. The conditions in a row combine, so a rule matches only when every condition in that row is true. * **Results** are the outcome a rule produces. A result is the path the care flow takes when the rule matches, and it appears as an output on the Decision node. Rules are evaluated top to bottom in the order the rows appear. A condition can also test against a list of values. `in option_1, option_2` matches when the data point holds either value, which keeps a rule to a single row instead of one row per option. ## The evaluation policy sets how many paths a decision takes [#the-evaluation-policy-sets-how-many-paths-a-decision-takes] The evaluation policy controls what happens when more than one rule matches: * **First match only**, the default, stops at the first matching rule and follows one path. Use it when the branches are mutually exclusive. * **Multiple matches** evaluates every rule and follows every matching path, so one decision can open several branches at once. ## Rules that share an outcome give a decision its "or" logic [#rules-that-share-an-outcome-give-a-decision-its-or-logic] A rule matches only when all of its conditions are true, so a single row is always an "and". To express an "or", give two or more rows the same result. For example, a care flow that escalates to a nurse on a high symptom score or a missed appointment needs two rules that both produce the result `Escalate`. Results with the same name collapse into one output on the Decision node, so the branch appears once no matter how many rules lead to it. Under **multiple matches**, both rules can match and the escalation still runs only once. ## A decision without a catch-all rule fails when nothing matches [#a-decision-without-a-catch-all-rule-fails-when-nothing-matches] A catch-all rule, the "else" row, produces an outcome when no other rule matches. Turn it on with **Include catch-all rule**. Always add one. If no catch-all is set and no rule matches, the Decision component fails during orchestration. ## Test a decision in Studio before a patient reaches it [#test-a-decision-in-studio-before-a-patient-reaches-it] A Decision component can be **tested directly in Studio**, which confirms which branch a given set of answers takes. It can also be **reused** within the same care flow, so the same logic isn't rebuilt everywhere it's needed. ## Next steps [#next-steps] **Next:** [Control when messages and forms expire](/docs/design-care-flows/message-and-form-expiration).