↔️ Conditions

A Condition acts as a decision gate in your workflow. It evaluates specified criteria and, if the condition is met (i.e., evaluates to true), the subsequent action(s) will run. If the condition is not met, the subsequent action(s) in that branch will be skipped.

Understanding Conditional Logic

Basic Condition Structure

Conditions in AppStruct follow this pattern:

IF [Variable] [Operator] [Value] THEN [Actions]

Example:

IF Device EQUALS "iOS" THEN Show iOS-specific alert

Workflow Canvas

Available Operators

Comparison Operators:

Equals: Exact match (case-sensitive for text)
Not Equals: Value does not match
Greater Than: Numeric comparison (5 > 3)
Less Than: Numeric comparison (3 < 5)
Greater Than or Equal: Inclusive comparison (5 >= 5)
Less Than or Equal: Inclusive comparison (3 <= 5)
Contains: Text contains substring (case-sensitive)
Does Not Contain: Text does not contain substring
Is Empty: Variable has no value or is null
Is Not Empty: Variable has a value

Boolean Operators:

Is True: Boolean value is true
Is False: Boolean value is false

Adding a Condition

Basic Setup

Select the element on your canvas (e.g., a "Submit" button) you want to attach the action to. Click on it to open left and right bar. In the left bar click Add Action → More actions…
In the canvas, click Add Condition beneath an existing action. A Condition node will appear in the workflow.
Configure the Condition:
- Choose the variable or parameter to evaluate. Examples might include:
  - Device (iOS, Android, Web)
  - A response variable from a previous HTTP request
  - A local storage value
  - An element input value
- Choose how to compare the selected variable (e.g., Equals, Not Equals, etc.).
- Specify the value to compare against. For instance, if the variable is Device, you might select iOS, Android, or Web.
Add Additional Conditions (Optional)
- Click Add condition to create additional comparisons. Each condition row is evaluated separately. If multiple conditions are present, they must all evaluate to true for the subsequent action(s) to run.
Save & Test
- Click Save. In Preview, trigger the workflow to see if the condition passes. If the condition is met, the next action(s) will execute; if not, those action(s) will be skipped.

Advanced Conditional Patterns

1. Multiple Condition Logic (AND)

When you add multiple conditions to a single condition node, they work as AND logic - ALL conditions must be true.

Example: User Validation

Condition 1: Email field IS NOT EMPTY
AND
Condition 2: Password field IS NOT EMPTY  
AND
Condition 3: Age field GREATER THAN 18

Only if all three conditions are true will the subsequent actions execute.

2. Complex Branching (OR Logic)

To create OR logic, use multiple separate condition nodes:

Action 1 (HTTP Request)
    ↓
Condition A: Status EQUALS "premium"
    ↓ (if true)
    Premium Actions...
    
Condition B: Status EQUALS "basic"  
    ↓ (if true)
    Basic Actions...
    
Condition C: Status EQUALS "trial"
    ↓ (if true)  
    Trial Actions...

3. Nested Conditions

Create sophisticated logic by chaining conditions:

Primary Condition: User Type EQUALS "admin"
    ↓ (if true)
    Secondary Condition: Feature Flag EQUALS "enabled"
        ↓ (if true)
        Show Admin Panel
        ↓ (if false)
        Show Coming Soon Message
    ↓ (if false - Primary)
    Show Regular User Interface

4. Data Type-Specific Conditions

String Conditions:

Username CONTAINS "@company.com"
Description IS NOT EMPTY
Status EQUALS "active"

Numeric Conditions:

Age GREATER THAN 21
Score GREATER THAN OR EQUAL 80
Items Count LESS THAN 10

Boolean Conditions:

Is Premium IS TRUE
Email Verified IS FALSE

Working with Variables in Conditions

1. HTTP Response Variables

After an HTTP request, you can access response data:

HTTP Request → Store response in "apiResponse"
    ↓
Condition: apiResponse.data.status EQUALS "success"
AND apiResponse.data.items.length GREATER THAN 0
    ↓ (if true)
    Display data
    ↓ (if false)
    Show "No results" message

2. Local Storage Variables

Access stored user preferences:

Page Load
    ↓
Condition: localStorage.theme EQUALS "dark"
    ↓ (if true)
    Apply dark theme styles
    ↓ (if false)
    Apply light theme styles

3. Form Input Variables

Validate user input in real-time:

Input Field Change
    ↓
Condition: email.value CONTAINS "@"
AND email.value CONTAINS "."
AND email.value LENGTH GREATER THAN 5
    ↓ (if true)
    Show green checkmark
    Remove error styling
    ↓ (if false)
    Show red error indicator
    Add error styling

Performance & Optimization

1. Condition Ordering

Order conditions by likelihood and performance:

// Good: Fast checks first
Condition 1: User Logged In IS TRUE (fast)
AND User Premium IS TRUE (fast)
AND API Response Valid IS TRUE (slower)

// Avoid: Slow checks first  
Condition 1: API Response Valid IS TRUE (slow)
AND User Logged In IS TRUE (fast)

2. Minimize Deep Nesting

Instead of:

Condition A
  ↓
  Condition B
    ↓
    Condition C
      ↓
      Condition D
        ↓
        Final Action

Use:

Condition: A IS TRUE
AND B IS TRUE  
AND C IS TRUE
AND D IS TRUE
  ↓
  Final Action

3. Cache Expensive Checks

Store complex condition results in local storage:

Page Load
    ↓
Condition: localStorage.userPermissionsCache IS EMPTY
    ↓ (if true)
    HTTP Request (Get Permissions)
    Local Storage (Save permissions)
    ↓ (if false)
    Use cached permissions

Example Use Cases

1. Device-Specific Flows

Condition: Device Equals iOS
Outcome: Only run certain actions (e.g., display iOS-specific UI or open an iOS app link) if the user is on iOS.

2. Validating Form Data

Condition: Form Input Value Not Equals "" (an empty string)
Outcome: Proceed with a data submission or next step only if the user has filled out the form.

3. User Authentication Status

Condition: User Token Is Not Empty AND Token Expiry Greater Than Current Time
Outcome: Allow access to protected content only for authenticated users with valid tokens.

4. Feature Flag Management

Condition: Feature Flag Equals "enabled" AND User Role Equals "beta_tester"
Outcome: Show new features only to beta testers when the feature flag is enabled.

Best Practices

Design Principles

Plan Condition Logic
- Map Decision Trees: Draw out your conditional logic before implementing
- Test All Paths: Ensure every condition branch is tested
- Document Complex Logic: Comment why certain conditions exist
Keep Conditions Simple
- Single Responsibility: Each condition should test one logical concept
- Readable Names: Use descriptive variable names
- Avoid Over-Complexity: Break complex conditions into multiple simpler ones
Handle Edge Cases
- Null/Empty Checks: Always validate data exists before using it
- Type Safety: Ensure data types match your expectations
- Default Behaviors: Define what happens when no conditions match

Performance Guidelines

Optimize Condition Performance
- Fast Checks First: Put quick conditions before slow ones
- Cache Results: Store expensive calculations
- Minimize API Calls: Don't make API calls just for condition checks
Error Prevention
- Validate Inputs: Check user inputs before processing
- Handle Failures: Plan for when conditions fail unexpectedly
- Graceful Degradation: Provide fallbacks when conditions can't be evaluated

User Experience

Provide Clear Feedback
- Loading States: Show progress during condition evaluation
- Error Messages: Explain why conditions failed in user-friendly terms
- Alternative Paths: Offer alternatives when primary conditions aren't met

Common Pitfalls & Solutions

1. Case Sensitivity Issues

Problem: Text comparison fails due to case differences

// Problematic
User Input: "ADMIN"
Condition: userRole EQUALS "admin" // Returns false

Solution: Normalize text before comparison

// Better approach
Condition: userRole.toLowerCase() EQUALS "admin"

2. Data Type Mismatches

Problem: Comparing string numbers with numeric operators

// Problematic  
Input Value: "25" (string)
Condition: age GREATER THAN 18 // May fail

Solution: Ensure consistent data types

// Better approach
Condition: Number(age) GREATER THAN 18

3. Undefined Variable Access

Problem: Accessing properties of undefined variables

// Problematic
Condition: user.profile.email EQUALS "[email protected]"
// Fails if user or profile is undefined

Solution: Check existence first

// Better approach
Condition 1: user IS NOT EMPTY
AND user.profile IS NOT EMPTY  
AND user.profile.email EQUALS "[email protected]"

Need Assistance?

If you encounter any challenges or require further guidance while building your app, please refer to the Documentation or, contact our support team at [email protected].

↔️ Conditions

Understanding Conditional Logic​

Basic Condition Structure​

Available Operators​

Adding a Condition​

Basic Setup​

Advanced Conditional Patterns​

1. Multiple Condition Logic (AND)​

2. Complex Branching (OR Logic)​

3. Nested Conditions​

4. Data Type-Specific Conditions​

Working with Variables in Conditions​

1. HTTP Response Variables​

2. Local Storage Variables​

3. Form Input Variables​

Performance & Optimization​

1. Condition Ordering​

2. Minimize Deep Nesting​

3. Cache Expensive Checks​

Example Use Cases​

1. Device-Specific Flows​

2. Validating Form Data​

3. User Authentication Status​

4. Feature Flag Management​

Best Practices​

Design Principles​

Performance Guidelines​

User Experience​

Common Pitfalls & Solutions​

1. Case Sensitivity Issues​

2. Data Type Mismatches​

3. Undefined Variable Access​

Need Assistance?​