useWorkspace.AI
Sign InGet Started

Decision Shape

Master the Decision diamond shape for conditional logic and branching in ISO 5807 flowcharts

Last updated: January 13, 2025
7 min read read

Decision Shape

The Decision shape is a diamond used for conditional logic and branching in flowcharts. It represents a yes/no question that determines which path the flow takes next.

What is a Decision Shape?

The Decision shape (also called a Decision Diamond or Conditional) represents:

  • A yes/no question or condition
  • A true/false evaluation
  • A binary choice point
  • A branch in the workflow

According to ISO 5807, the Decision symbol must have exactly two or more paths leading out, representing different outcomes.

When to Use

Use the Decision shape for:

  • Yes/No questions: "Is user logged in?", "Is balance sufficient?"
  • Comparisons: "Is age >= 18?", "Is quantity > 0?"
  • Validations: "Is format valid?", "Is password correct?"
  • State checks: "Is file found?", "Is connection active?"
  • Boolean conditions: Any expression that evaluates to true/false

ISO 5807 Standard

According to ISO 5807, the Decision symbol is defined as:

  • A diamond shape (rhombus)
  • Contains a question or condition
  • Has two or more exit paths
  • Each path must be clearly labeled (Yes/No, True/False, or specific conditions)

The diamond shape is specifically reserved for decision points and should not be used for other purposes.

Visual Appearance

In DiagramKit.AI, the Decision shape appears as:

  • Dimensions: 120×120 pixels (perfect diamond)
  • Color: Light yellow (#fefce8)
  • Border: Gold (#ca8a04)
  • Shape: Diamond rotated 45 degrees

Best Practices

✅ Good Usage

[Start]
   ↓
[Get user age]
   ↓
<Is age >= 18?>
  ↙        ↘
Yes        No
 ↓          ↓
[Grant]   [Deny]
[Access]  [Access]
  ↓          ↓
[End]     [End]
  • Write as a clear question with a question mark
  • Label all exit paths (Yes/No, True/False)
  • Keep questions simple and binary
  • Use consistent labeling throughout the flowchart

❌ Avoid

  • ❌ Statements: "User is valid" (use "Is user valid?" instead)
  • ❌ Actions: "Check validity" (use "Is valid?" instead)
  • ❌ Multiple questions: "Is valid and active?" (split into two decisions)
  • ❌ Unlabeled paths (always label Yes/No)

Common Examples

Example 1: User Authentication

[Enter credentials]
   ↓
<Is password correct?>
  ↙              ↘
Yes              No
 ↓                ↓
<Is 2FA enabled?>  [Show error]
  ↙        ↘           ↓
Yes        No        [End]
 ↓          ↓
[Send code] [Login success]

Example 2: Data Validation

[Receive input]
   ↓
<Is format valid?>
  ↙          ↘
Yes          No
 ↓            ↓
<Is within    [Return error]
 range?>         ↓
  ↙    ↘       [End]
Yes    No
 ↓      ↓
[Save] [Reject]

Example 3: Loop with Decision

[Initialize counter = 0]
   ↓
<Is counter < 10?>
  ↙            ↘
Yes            No
 ↓              ↓
[Process item]  [End]
 ↓
[Increment counter]
 ↓
(loop back to decision)

Writing Good Decision Questions

Strong Questions (Recommended)

  • "Is balance > 0?"
  • "Is user authenticated?"
  • "Is file found?"
  • "Is quantity available?"
  • "Has timeout occurred?"

Weak Questions (Avoid)

  • "Check balance" (not a question)
  • "Balance" (too vague)
  • "Valid?" (incomplete question)
  • "Process user if authenticated" (too complex)

Multiple Conditions

Binary Decision (Most Common)

<Is valid?>
  ↙      ↘
Yes      No

Three-Way Split

<Check status>
  ↙    ↓    ↘
Low  OK  High

Complex Logic (Split into Multiple Decisions)

❌ Wrong: <Is A and B or C?>

✅ Correct:
<Is A?>
  ↙  ↘
Yes   No → [End]
 ↓
<Is B?>
  ↙  ↘
Yes   No
 ↓     ↓
<Is C?>

AI Prompt Tips

Use these prompts to add Decision shapes with AI:

add a decision to check if user is logged in

insert a validation decision after the input

create a decision point asking if balance is sufficient

add a yes/no decision for age verification

Programming Equivalents

Decision shapes represent conditional statements:

JavaScript/TypeScript:

// Decision: Is age >= 18?
if (age >= 18) {
  // Yes path
  grantAccess();
} else {
  // No path
  denyAccess();
}

// Decision: Is user authenticated?
const result = isAuthenticated() ? login() : showError();

Python:

# Decision: Is balance > 0?
if balance > 0:
    # Yes path
    process_payment()
else:
    # No path
    show_insufficient_funds()

Pseudocode:

Decision: Is quantity available?
  IF quantity > 0 THEN
    Process order
  ELSE
    Show out of stock
  END IF

Path Labeling Conventions

Standard Labels

  • Yes/No - Most common, universal
  • True/False - Programming contexts
  • Pass/Fail - Testing scenarios
  • Valid/Invalid - Validation checks
  • Found/Not Found - Search operations

Specific Conditions

<Check file size>
  ↙        ↘
< 10MB    >= 10MB

<User type>
  ↙      ↘
Admin   Regular

Connections

Decision shapes typically connect:

Input from:

  • Process shapes (that evaluate conditions)
  • Data I/O shapes (after receiving input)
  • Preparation shapes (after setup)
  • Other Decision shapes (nested conditions)

Output to:

  • Process shapes (for each branch)
  • Other Decision shapes (nested logic)
  • End symbols (for termination paths)
  • Loop back to previous steps

Common Patterns

Validation Chain

[Input data]
   ↓
<Is format valid?> → No → [Error]
   ↓ Yes
<Is in range?> → No → [Error]
   ↓ Yes
<Is unique?> → No → [Error]
   ↓ Yes
[Save data]

Loop Pattern

[Initialize i = 0]
   ↓
   ┌←←←←←←←←←←←←←┐
   ↓             ↑
<Is i < 10?>     ↑
   ↓ Yes         ↑
[Process item]   ↑
   ↓             ↑
[i = i + 1]      ↑
   └→→→→→→→→→→→→→┘
   ↓ No
[End]

Error Handling

[Attempt operation]
   ↓
<Success?>
  ↙      ↘
Yes      No
 ↓        ↓
[Log]    <Retries left?>
 ↓         ↙        ↘
[Next]   Yes        No
          ↓          ↓
      (retry)    [Fail]

Common Mistakes

Mistake 1: Using for Actions

❌ Wrong: <Process payment> (action, not question) ✅ Correct: <Is payment valid?> (yes/no question)

Mistake 2: Unlabeled Paths

❌ Wrong:

<Is valid?>
   ↙    ↘
[Save] [Error]

✅ Correct:

<Is valid?>
  ↙       ↘
Yes       No
 ↓         ↓
[Save]  [Error]

Mistake 3: Complex Conditions

❌ Wrong: <Is logged in and has permission and not expired?> ✅ Correct: Split into three separate Decision shapes

Mistake 4: Missing Exit Paths

❌ Wrong: Decision with only one exit path ✅ Correct: Always have at least two exit paths

Decision Tables Alternative

For complex multi-condition logic, consider using a decision table instead of nested diamonds:

Condition 1 | Condition 2 | Action
------------|-------------|-------
Yes         | Yes         | Action A
Yes         | No          | Action B
No          | Yes         | Action C
No          | No          | Action D

Then implement as:

<Condition 1?>
  ↙        ↘
Yes        No
 ↓          ↓
<Cond 2?>  <Cond 2?>
 ↙  ↘      ↙  ↘
A    B    C    D

Related Shapes

Pro Tip: Keep decisions binary (Yes/No) whenever possible. If you need more than 3 branches, consider refactoring into multiple decisions or using a different diagram type!

Next Steps