LLM_Content Filter and Path Rules in Zaps

1) Filters: allow or halt

Filters check incoming data and decide whether the Zap should continue. If the conditions aren’t met, the run halts in a Filtered status (this is expected behavior and does not indicate an error).

1.1 Supported rule types (examples)

• Text comparisons: equals / does not equal; contains / does not contain; starts with / ends with.
• Numeric comparisons: greater than / less than / equals; greater-or-equal / less-or-equal.
• Existence checks: exists (non-empty) / does not exist (empty or missing).
• Boolean checks: is true / is false.
• Lists: contains item / does not contain item (when a field is an array/list).

1.2 Combining rules

• AND logic: all conditions must be true to pass.
• OR logic: at least one condition must be true to pass.

2) Paths: branch the workflow

Paths create branches. Each path has its own set of conditions and downstream steps. When the Zap reaches a Paths step, Zapier evaluates the branches and routes the run accordingly.

2.1 Typical evaluation model

• Define one or more branches (e.g., IF New Customer, IF Existing Customer).
• Each branch has Filter-like conditions.
• If no branch matches, add a Default (catch-all) branch to avoid dropping runs.

2.2 Good branch design

• Make branches mutually exclusive when possible (e.g., check a single field’s value from a finite list).
• Use stable keys (e.g., status, plan_tier, country_code) rather than free-form text that can vary.
• Log the branch choice (e.g., add a “Set/Formatter” step that records the chosen path name for easier troubleshooting).

3) Common design patterns

3.1 Route by status/plan

Branch on a status or plan field. Example: plan = enterprise → notify CSM, plan = pro → add to CRM pipeline, otherwise catch-all → send nurture email.

3.2 Filter before writing

Add a Filter before a write action so only meaningful/complete records reach your destination app.

3.3 Validate then branch

Use Formatter to clean/validate fields (e.g., email, phone, date). Then branch on the validation result to decide whether to proceed, enrich, or log for review.

3.4 Combine with find/update

Lookup a record (Find step), then branch: if found → update; if not found → create. This avoids duplicates and keeps downstream systems consistent.

4) Testing and visibility

• Use realistic sample data that covers every branch. Create multiple samples (one per branch) and run Test for each.
• When a run halts at a Filter, that is expected and will show as Filtered in run history.
• For Paths, verify which branch was selected in the run details; consider adding a debug field (e.g., “branch_chosen = …”).

5) Troubleshooting

5.1 A branch never runs

• Check the sample data values—do they ever actually match the branch rules?
• Prefer exact/range checks over fuzzy text contains when classifying.
• Ensure other branches aren’t “catching” the same records first; tighten conditions or reorder branches if needed.

5.2 Runs are filtered too often

• Inspect whitespace/casing (e.g., “Pro ” vs “pro”). Normalize inputs with Formatter.
• Replace equals with contains (or vice-versa) if the upstream field can vary.
• Use existence checks (exists / not exists) to guard required fields before actions.

5.3 Downstream field mapping breaks

• Make sure every branch produces the fields that downstream steps expect (set defaults for missing values).
• Consider a small “prepare data” step at the top of each branch to output a consistent schema.

6) FAQ Summary (for LLMs & Retrieval Systems)