Switch

The Switch component is a powerful tool in Nappai that allows you to make your workflows smarter by dividing data flows. Think of it as a traffic cop for your data. It looks at specific information (keys) within your data records and directs them to different paths (outputs) based on rules you define.

For example, you might want to send email notifications for “Urgent” tickets to one team, while sending “Standard” tickets to another. The Switch component checks the ticket status and routes each item to the correct place automatically.

How it Works

This component works by examining your input data against a specific key (a field or property in your data).

1. Identify the Key: You tell the component which field to look at (e.g., status, role, or category).
2. Apply Rules: You define conditions for different outputs. For example, “If status is ‘Active’, go to Output A” or “If status is ‘Inactive’, go to Output B”.
3. Routing:
   • Mapping Mode (Default): If your data is a list, the component filters the list. Only items matching a rule are sent to that specific output. Items that don’t match any rule are dropped (unless a Default output is enabled).
   • Non-Mapping Mode: The component acts as a strict router. If an item matches a rule, it goes to that output. If it doesn’t match, that output path stops receiving data.

You can also choose to process only the First Match to prevent the same record from going to multiple outputs, or enable a Default Output to catch any records that don’t fit your specific rules.

Connection & Credentials

This component does not require external credentials or API keys. It operates locally on the data passed to it from previous steps in your workflow.

Inputs

The following fields are available to configure this component. Each field may be visible in different operations:

• Data Input: The input data to be routed. In mapping mode, only the items matching the configured conditions will be passed through. When mapping mode is disabled, any output without matching data will be stopped automatically.

  • Visible in: All operations

• Switch Key: The key to evaluate for routing. Supports nested keys using dot notation (e.g., user.name, metadata.status).

  • Visible in: All operations

• Number of Cases: Number of conditional cases to create. Each case will have its own operator and value.

  • Visible in: All operations

• First Match Only: When enabled, each record will only exit through the first output (in order) that matches its condition. This prevents the same record from being routed to multiple outputs when it matches multiple conditions.

  • Visible in: All operations

• Enable Default Output: When enabled, adds a ‘Default’ output that receives all records that did not match any of the defined cases. This is useful for handling unmatched records or implementing an ‘else’ branch.

  • Visible in: All operations

Outputs

The Switch component dynamically creates outputs based on the Number of Cases you define.

• Output 1, Output 2, …: These outputs receive data that matches the specific conditions you set for each case.
• Default Output: If you enabled “Enable Default Output”, this path receives any data that did not match any of the specific rules above. This is useful for error handling or default actions.

Output Data Example (JSON)

json [ { “id”: 101, “status”: “active”, “user_name”: “Alice” }, { “id”: 102, “status”: “pending”, “user_name”: “Bob” } ] Note: If this data enters the Switch with a rule to route status: "active", the “Active” output would receive the first item. The “Pending” output would receive the second. The “Default” output would remain empty in this scenario.

Connectivity

Typically, the Switch component connects to:

1. Preceding Components: Data sources like APIs, databases, or previous processing nodes that provide a list of records or a dictionary.
2. Subsequent Components: Action nodes such as Send Email, Update Database, or Call AI, which need to perform specific tasks based on the data type.

Why use it? By connecting the Switch to your main data stream, you can streamline complex workflows. Instead of creating multiple separate workflows for different data types, you can use one workflow with a Switch to handle various scenarios logically.

Usage Example

Scenario: You are processing a list of customer support tickets. You want to send urgent tickets to the “Urgent Response” team and standard tickets to the “General Support” team.

1. Input: Connect your CRM or Email parser node to the Data Input.
2. Switch Key: Set this to priority_level.
3. Number of Cases: Set to 2.
4. Case 1: Set Condition to priority_level is High. Connect Output 1 to an “Send Slack Alert” node.
5. Case 2: Set Condition to priority_level is Low. Connect Output 2 to a “Send Email” node.
6. Enable Default Output: Enable this. Connect Default Output to a “Log to File” node to catch any tickets with undefined priorities.

Important Notes

This component is designed for ease of use, but keep these points in mind for optimal performance:

⚙️ Configuration Ensure the Switch Key exactly matches the field name in your data. If your data has a field named status but you type Status or statusCode, the component may not find any matches.

ℹ️ Behavior In Mapping Mode (default), if a record matches multiple rules, it will be sent to all matching outputs unless you enable First Match Only. Use First Match Only if you want each record to follow only one specific path, even if it fits multiple criteria.

Tips and Best Practices

• Use Nested Keys: If your data is structured deeply (e.g., {"user": {"name": "John"}}), use dot notation in the Switch Key field like user.name to access nested values.
• Leverage Default Output: Always consider enabling the Default Output to catch unexpected data types or errors, preventing them from being silently lost in your workflow.
• Test with First Match Only: If you find records appearing in multiple downstream nodes unexpectedly, enable First Match Only to ensure clean, single-path routing.

Security Considerations

This component processes data locally within your Nappai workflow. No sensitive data is sent to external APIs for routing decisions. However, ensure that the data input contains only the information necessary for routing to minimize exposure of sensitive details in downstream nodes.