> ## Documentation Index
> Fetch the complete documentation index at: https://flywheel.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 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
Select one or more events that start the drop-off monitoring. Examples: `trial_started`, `cart_created`, `signup_initiated`.
Configure the events you expect users to complete after the initial event.
The specific event you expect users to complete (part of Expected Events configuration).
How long to wait before considering it a drop-off (number value).
Time unit for the delay. Options: `seconds`, `minutes`, `hours`, `days`, `weeks`, `months`.
Priority order for multiple drop-off events. Lower numbers have higher priority.
The drop-off event data generated by Flywheel when the expected event didn't occur.
Unique identifier for this drop-off event.
Always `$fw_drop_off` for drop-off events.
ISO datetime when the drop-off was detected.
Contains drop-off specific data and system properties.
Always `flywheel` for system-generated events.
Internal user identifier.
Name of the last event the user completed that triggered the drop-off monitoring.
Full details of the original event that started the drop-off monitoring, including all event properties and custom data.
Comprehensive user information for the user who dropped off.
Unique user identifier.
Your company's external user identifier.
User's primary email address.
User's first name.
User's last name.
Current subscription status: `incomplete`, `incomplete_expired`, `trialing`, `active`, `past_due`, `canceled`, `unpaid`, `paused`, `inactive`.
Payment processor used: `stripe` or `paddle`.
Monthly recurring revenue from this user.
Lifetime value of the user.
ISO datetime of user's first payment.
ISO datetime of user's next scheduled payment.
ISO datetime when subscription will be cancelled (if applicable).
Additional contact information and preferences.
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