CEL Expressions

Write dynamic conditions for Gravity Rail workflows using CEL (Common Expression Language). Use it to control access to tasks, route conversations, and trigger automations.

Quick Start

CEL expressions evaluate to true or false. Here are common patterns:

cel

Operators

Available Variables

member

Information about the current member.

Available in: All contexts where a member is associated — event rules, ability conditions, router tasks, and edge routing conditions. All fields in the table below are available on every surface.

Examples:

cel

member.experiments (A/B testing)

Map of Experiment slug → assigned Group slug. Populated on runtime surfaces (Actions, automatic task edges) when a CEL expression reads a slug and lazy assignment runs.

Available in: Event rule conditions, automatic task edge CEL, and other assignment-capable runtime surfaces. Not available for side-effect-free assignment on filters or journey goal definition CEL.

Lazy assignment: First read of a slug on a runtime surface may assign the Member (Experiment must be running, eligibility CEL must pass), record exposure, then evaluate the branch.

Unassigned Members: Missing key → equality checks evaluate false. Use "slug" in member.experiments when you need to detect assignment explicitly.

cel

See Experiments (A/B Testing) for eligibility filtering and reporting.

chat

Information about the current conversation.

Available in: Message event rules, router tasks, ability conditions.

Channel values: "phone-sms", "phone-voice", "email", "web-chat", "web-voice", "cli", "frame", "discord", "slack", "direct-message"

Examples:

cel

phone_number

The workspace phone number the current chat arrived on. Only populated for chats with a linked workspace phone number — typically phone-voice and phone-sms channels. Absent for web-chat and other channels.

Available in: Message event rules, router tasks, and ability conditions on chats that came in via a workspace phone number.

Examples:

cel

task

Information about the current task.

Available in: Ability conditions, router task edges.

assignment

Information about the current assignment (a member's progress through a workflow).

Available in: Ability conditions, task guards, edge conditions, and event rules on assignment / task events.

assignment.collections.* vs member.collections.*

These two namespaces have the same shape but different scope:

• assignment.collections.<form>.* sees only records linked to the current Assignment through the agent's data-access action. Use this for per-encounter checks like "did the agent collect a reason on this call?".
• member.collections.<form>.* sees the Member's lifetime records — every record ever created for that Form, across all Assignments and all time. Use this for historical checks like "has the Member ever completed intake?".

Pick deliberately. A common bug is writing member.collections.call_log.latest.data.reason for a current-call check, then having the rule fire on a leftover record from a previous call.

assignment.form_data.* and assignment.data.* are not valid paths. Use member.form_data.<form>.<field> for singular Member-scoped data, or assignment.collections.<form>.* for current-Assignment collection records.

workspace

Workspace-scoped configuration data, keyed by DataType slug.

Available in: All contexts (event rules, ability conditions, router task conditions, edge conditions).

Access pattern: workspace.<slug>.<field>, where <slug> is the sanitized slug of a workspace-scoped DataType (one configured with record_scope="workspace"). The value reflects the field values of the latest workspace-scoped record for that DataType. Fields that have no record yet return their default values.

The record's created_at and external_id scalars are not exposed on this namespace today — only the field values from the record's data are surfaced. Use member- or assignment-scoped collection paths (e.g. member.collections.<slug>.latest.created_at) if you need record metadata.

Examples:

cel

Setup: Workspace-scoped DataTypes are created in the workspace's Data Types settings with Record Scope set to "workspace". Each workspace-scoped DataType is always a collection; the CEL namespace reflects the latest record.

record

Information about the data record that triggered the event.

Available in: Data record event rules only (data_record:created, data_record:updated, data_record:deleted).

Examples:

cel

changes

Field-level change tracking for record updates.

Available in: data_record:updated event rules only.

Examples:

cel

datetime

Current time in your workspace's timezone.

Available in: All contexts.

Examples:

cel

tool_invocations

List of tools the AI called this turn. Each entry has name (string) and args (map of argument values).

Available in: Edge conditions on task transitions only. Evaluated after each agent turn.

Examples:

cel

Note: Tool names for Data Access abilities follow the pattern update_{data_type_slug}_record, create_{data_type_slug}_record, etc. Use has(t.args.field) to check field presence before comparing values.

message

The content of the current message.

Available in: Router tasks and message event rules only.

cel

Built-in Functions & Macros

Standard CEL functions available in all contexts:

Examples:

cel

Custom Functions

Common Patterns

VIP Handling

cel

Business Hours

cel

Form Completion Check

cel

Channel-Specific Logic

cel

Combined Conditions

cel

Content Filtering

cel

Record Status Change

cel

Tool Invocation Routing (Edge Conditions)

cel

Data Type Validation

CEL expressions can be used within Data Types to control field behavior and validate input.

Conditional Field Options

Use visibleWhen on enum options to show or hide choices based on other field values. The expression evaluates in the form editing context, where field names are available directly.

Example: Show California-specific options only when the state is California.

cel

This would be set on enum options that should only appear for California residents. When the user selects "CA" in the state field, these options become visible.

Field Validation

Use validateCel on fields to add custom validation rules. The expression should return:

• true if the value is valid
• An error message string if the value is invalid

Access field values using record.data.<field>.

Example: Require age to be 18 or older.

cel

Example: Require email for non-SMS contacts.

cel

Example: Validate date is in the future.

cel

Tips

1. Use labels for permissions — Labels like "vip", "verified", "admin" are the cleanest way to control access.

2. Handle missing data — Use has(field) to check if a field exists before accessing it. For example, has(member.phone) && member.phone != "" safely checks for a phone number. If a field doesn't exist and you access it directly, the expression evaluates to false rather than erroring.

3. Test your expressions — The CEL editor validates syntax in real-time. Invalid expressions show a red error indicator and cannot be saved.

4. Keep it readable — Break complex logic into multiple rules when possible.

5. All available functions appear in the editor — Click the "Functions" dropdown in the CEL editor toolbar to see all built-in and custom functions with signatures and examples.

Related

• Actions — Use CEL conditions to control when automations fire
• Abilities — Add CEL conditions to control when abilities activate
• Qualifications — Use CEL in formula criteria for evaluation