Drop-off Trigger

Start an agent run when users fail to complete expected actions within a specified timeframe

How Drop-off Triggers Work

1. Monitor Events: The system tracks when users perform the initial event
2. Set Expectations: You define what actions users should take next
3. Wait and Watch: The system waits for the expected follow-up events
4. Trigger on Absence: If expected events don’t occur within your timeframe, the agent run starts

Unlike workflow drop-off triggers which follow a fixed recovery path, agent drop-off triggers pass the full drop-off context to the language model. The agent can then reason about why the user may have dropped off, check additional data with tools like Find Event, and take contextually appropriate action.

Configuration

Inputs

Initial Events · string[] · required

Select one or more events that start the drop-off monitoring. Examples: trial_started, cart_created, signup_initiated.

Expected Events · object[] · required

Configure the events you expect users to complete after the initial event.

Event Name · string · required

The specific event you expect users to complete (part of Expected Events configuration).

Delay Value · number · required

How long to wait before considering it a drop-off (number value).

Delay Unit · enum · required

Time unit for the delay. Options: seconds, minutes, hours, days, weeks, months.

Sort Order · number

Priority order for multiple drop-off events. Lower numbers have higher priority.

Outputs

event · object · required

The drop-off event data generated by Flywheel when the expected event didn’t occur.

Show Event Properties

event.event_id · string · required

Unique identifier for this drop-off event.

event.event_name · literal · required

Always $fw_drop_off for drop-off events.

event.timestamp · string · required

ISO datetime when the drop-off was detected.

event.custom_properties · object · required

Contains drop-off specific data and system properties.

event.custom_properties.$fw_event_source · literal · required

Always flywheel for system-generated events.

event.custom_properties.$fw_user_id · string · required

Internal user identifier.

event.custom_properties.last_completed_event_name · string · required

Name of the last event the user completed that triggered the drop-off monitoring.

event.custom_properties.last_completed_event · object · required

Full details of the original event that started the drop-off monitoring, including all event properties and custom data.

org_user · object · required

Comprehensive user information for the user who dropped off.

Show User Properties

org_user.id · string · required

Unique user identifier.

org_user.org_assigned_user_id · string

Your company’s external user identifier.

org_user.primary_email · string

User’s primary email address.

org_user.first_name · string

User’s first name.

org_user.last_name · string

User’s last name.

org_user.subscription_status · enum

Current subscription status: incomplete, incomplete_expired, trialing, active, past_due, canceled, unpaid, paused, inactive.

org_user.payment_processor · enum

Payment processor used: stripe or paddle.

org_user.mrr · number

Monthly recurring revenue from this user.

org_user.ltv · number

Lifetime value of the user.

org_user.first_payment_date · string

ISO datetime of user’s first payment.

org_user.next_payment_date · string

ISO datetime of user’s next scheduled payment.

org_user.cancels_at · string

ISO datetime when subscription will be cancelled (if applicable).

org_user.contact_info · object

Additional contact information and preferences.

org_user.custom_properties · object

Custom user properties you’ve defined.

The system creates drop-off events with the name $fw_drop_off for all drop-off triggers.

Use Cases

Trial Conversion Recovery

Initial Event: trial_started
Expected Event: subscription_created
Drop-off Delay: 7 days
Agent behavior: Check usage patterns, assess activation status, send personalized conversion email or assign to sales

Cart Abandonment Rescue

Initial Event: cart_created
Expected Event: purchase_completed
Drop-off Delay: 2 hours
Agent behavior: Analyze cart contents, check for prior purchases, send targeted recovery message via Smart Message

Onboarding Completion

Initial Event: account_created
Expected Events:
  - profile_completed (24 hours)
  - first_project_created (3 days)
  - team_invited (7 days)
Agent behavior: Identify which step stalled, search for related events, send step-specific guidance or escalate to CSM

Feature Adoption Push

Initial Event: feature_introduced
Expected Event: feature_activated
Drop-off Delay: 5 days
Agent behavior: Check user tier and usage history, generate contextual tips email, set custom property for follow-up tracking

Best Practices

Choose Appropriate Timeframes

• Consider your typical user behavior patterns when setting delays
• Account for different user segments — some may need more time
• Start with longer delays and optimize based on data from the Runs tab

Segment Your Audiences

• Use trigger conditions to create different drop-off flows for different user types
• Consider factors like subscription tier, user role, or geographic location
• Let the agent prompt handle nuanced segmentation logic

Monitor and Adjust

• Track which drop-off triggers are most effective in the Runs tab
• Review agent reasoning to ensure it’s making appropriate recovery decisions
• Adjust timing and prompt instructions based on actual conversion data
• A/B test different delay periods and agent strategies