Workflow Timing & Tasks

Workflow timing issues account for roughly 15% of troubleshooting tickets. They show up as internal tasks arriving at unexpected times, tasks assigned to the wrong team member, workflows firing more than once for the same contact, or contacts stuck in a workflow stage that should have moved on.

Most of these trace back to how workflows interact with each other. In a system with 300+ workflows, actions in one workflow can trigger conditions in another, creating cascades that are hard to predict without understanding the full chain.

What it looks like

• An internal task notification arrives at 2am instead of during business hours.
• A task is assigned to the wrong team member (or to nobody).
• A contact receives the same SMS or email twice within minutes.
• A workflow fired for a contact who should not have qualified (wrong pipeline stage, wrong tag, wrong package type).
• A contact's pipeline card is stuck and has not moved for days, even though they are attending classes.
• Multiple task notifications fire for the same contact on the same day.

Tasks arriving at wrong times

Root cause

Internal task actions in workflows use the location's timezone setting. If the timezone is misconfigured (for example, set to UTC instead of the studio's local timezone), tasks scheduled for “9am” will fire at 9am UTC, which could be 2am or 7pm at the actual studio location.

A second cause: some workflows use “Wait X hours” actions that do not account for timezone. If a contact enters a workflow at 11pm and the workflow has a “Wait 8 hours” step followed by a task creation, the task fires at 7am. This is technically correct, but if the workflow design intended “next business morning,” the wait step does not enforce that.

How to diagnose

1. Check the task timestamp: in the contact's activity timeline, find the task creation entry. Note the exact time.
2. Check the location timezone: in Grow, go to Settings, then Business Profile. The timezone is listed there. Compare it to the studio's actual timezone.
3. Check the workflow wait steps: if the task is created after a wait step, calculate when the contact entered the workflow and add the wait duration. If the result matches the unexpected time, the wait step is the cause.

Resolution

Tasks assigned to the wrong person

Root cause

The User Assignment workflows assign contacts to team members when they first enter the system. The assignment is configured per location: each studio has its own user assignment workflow with a specific team member set in the action.

When a studio's team changes (a manager leaves, a new hire starts), the workflow still points to the old team member until it is manually updated. Contacts continue to be assigned to someone who may no longer be at the studio.

A second cause: some workflows use “Assign to specific user” while others use “Assign to contact owner.” If the contact has no owner (because the assignment workflow did not fire), the “assign to owner” action fails silently and the task has no assignee.

How to diagnose

1. Check the contact's assigned user: on the contact profile, look at the “Assigned To” field. If it is empty, the assignment workflow did not fire. If it shows a former team member, the workflow has not been updated.
2. Check the assignment workflow: find the location's “01. Systems | Assign User” workflow and look at the “Assign to user” action to see who it is currently assigning to.

Resolution

For the specific contact: manually update the Assigned To field to the correct team member.

Workflows firing multiple times

Root cause

Most workflows in the STRONG system have “Allow Re-entry” enabled. This is by design: when a contact's field values change (via Core sync, manual edit, or another workflow), the contact can re-enter a workflow they have already been through. In most cases, the workflow's internal conditions prevent duplicate processing (for example, checking the pipeline status before acting).

Double-firing happens when a workflow's trigger condition is met twice in quick succession, faster than the workflow can process the first entry. The most common trigger: two consecutive Core syncs that both push field changes within minutes of each other.

How to diagnose

1. Check the contact's timeline: look for two instances of the same workflow entry within minutes of each other. Each workflow entry shows as a distinct event with a timestamp.
2. Check for duplicate messages: in the Conversations tab, look for the same SMS or email sent twice with nearly identical timestamps.
3. Check Audit Logs: look for two Integration sync entries close together. If both syncs pushed changes to the same field (for example, Attendance Total), each would have triggered the watching workflow independently.

Resolution

For the specific contact: no action needed if the duplicate was just a duplicate notification or SMS. If the duplicate firing caused incorrect data (for example, Pipeline Visits incremented twice instead of once), manually correct the affected field.

For recurring double-fires at a specific location, escalate to HQ. The fix may involve adding a debounce condition to the workflow (for example, checking the last execution time before acting).

Contacts stuck in a workflow

Root cause

A contact enters a workflow and reaches a “Wait” step, but the condition to proceed past the wait is never met. Common scenarios:

• A wait step says “Wait until Active Package contains X” but the contact's package name changed and no longer matches the expected value.
• A wait step says “Wait 24 hours” followed by a condition check. The condition fails, and the workflow has no fallback path, so the contact sits in limbo.
• A contact entered a workflow before it was fully configured. They are waiting at a step that was later modified, but the modification only applies to new entries, not contacts already in the queue.

How to diagnose

1. Check the workflow enrollment: in the contact's timeline, find the workflow entry and note when they entered.
2. Check for completion: if there is an entry event but no corresponding completion or exit event, the contact is still enrolled.
3. Check the workflow steps: open the workflow in the builder and identify which step the contact would be on based on their entry time and the wait durations before that step.

Resolution

Remove the contact from the workflow manually. In the workflow builder, you can search for enrolled contacts and remove them individually. After removal, verify that the contact's custom fields and tags are in the correct state. If the stuck workflow was supposed to update a field or tag, you may need to set it manually.