Note:
The 'locked status' of Workflows cannot be packaged. By default, all workflows are deployed in the subscriber org in an unlocked, read-only mode.
Troubleshooting workflow issues
Use this checklist when a workflow rule is missing, not firing, or firing with the wrong results.
Workflow does not trigger
- Check the following before investigating the rule logic:
- The rule exists in the latest published application version.
- The module and record type match the rule's selected module.
- The trigger type matches the actual record event or date condition.
- The record meets the condition set and the rule is not restricted by a missing field or invalid value.
- The application version was published after the latest workflow change.
If the rule is visible in the developer console but not firing in subscriber orgs, review packaging, plan, or publish-state dependencies before investigating the action itself.
Rule is locked or changes do not save
If a rule appears locked, cannot be deleted, or keeps reverting after you make updates, check the app version state before changing the workflow again.
- Confirm that the current application version is published correctly.
- Save the workflow definition again after the latest app state is consistent.
- Refresh the rule editor and validate whether the trigger, condition, or action config still matches the latest published version.
This issue often points to a pending app-state change rather than a workflow logic error. When an earlier version remains unpublished, the workflow editor can block edits until the app state is resolved.
Workflow fires for the wrong records
If the rule triggers too often or for the wrong records, review the condition logic:
- Confirm that the criteria are grouped correctly with AND and OR logic.
- Check whether the trigger is set to Any field is modified instead of a specific field change.
- Verify that lookup, date, and required-field values are not producing unintended matches.
- Validate the rule in a test subscriber org using sample records that are close to real production conditions.
Trigger cascades or repeated execution
If a workflow rule causes a chain of repeated updates, review the trigger and action design before changing the rule again.
- Check whether the rule updates a field that triggers the same rule again.
- Confirm that a create-record or update action is not starting another workflow in the same module.
- Review the exact sequence of actions to see whether the rule creates a record that re-matches the rule criteria.
- Test the rule with a low-volume sample record so the repeated trigger pattern is easier to isolate.
A workflow that fires repeatedly usually indicates a self-triggering loop or a second rule that shares the same criteria.
Workflow sends the wrong email or wrong call activity
If a workflow is firing but the email or call action is incorrect, validate the following:
- The correct recipients and sender values are selected in the email action.
- The email template is the correct one for the module and use case.
- The call or task action is assigned to the correct owner or host.
- The assignee or subject values are not empty and do not depend on fields that are not present in the target record.
Scheduled workflow action is missing or delayed
Scheduled actions may not run immediately if conditions are evaluated later or if the rule is waiting on the next scheduled evaluation. Check the following:
- The rule is configured for the correct date or time field.
- The record still meets the rule conditions when the scheduled evaluation occurs.
- The scheduled time is not set in the past in a way that prevents execution.
- The action is still valid after a record update, delete, or lead conversion.
Workflow scheduling is sensitive to the record state at execution time, so always validate the record lifecycle before assuming the rule is broken.
Date or time logic does not match expected UTC conversion
If a workflow seems to fire at the wrong time or compares a date incorrectly, the problem is often a timezone or UTC conversion mismatch rather than a missing trigger. Review the following before changing the workflow logic:
- Confirm the target date field is stored and interpreted in the expected timezone for the application and subscriber org.
- Check whether the rule compares a manually converted UTC value with a record value that is already localized.
- Validate any custom formula or variable used to calculate the target date before the rule runs.
- Test the same rule in a sample record with a known date near the edge of the day or week boundary.
A time-based rule can appear broken when the workflow evaluates an internal UTC value while users expect a local business-time result. Always validate the rule against real scheduled records and time-zone boundaries before publishing a change.
Custom action configuration does not persist
If a custom action setting keeps reverting to a placeholder value or appears to lose its configuration after saving, check the action definition before you publish the app version.
- Confirm that the selected custom function, webhook URL, or action variable is still valid after the last edit.
- Review whether a field name, API name, or variable reference was renamed without updating the workflow action.
- Save the workflow and refresh the action configuration to confirm the values remain in place.
- Validate the custom action in a test subscriber org before shipping the version to production users.
Workflow works in one org but not another
- If a workflow works in one subscriber org and not another, review the following:
- The subscriber org is on the correct application version.
- Different profiles or role permissions affect who can trigger or receive the action.
- The workflow is not gated by a pricing-plan or visibility dependency.
- The rule was published after the latest change and the subscriber org completed the upgrade.
Deleting a packaged workflow rule is a destructive change.
Removing a workflow rule from a published application will remove it from the subscriber orgs as well. This will stop notifications, task creation, and follow-up actions in subscriber orgs after the next upgrade. Validate the replacement process in a test org before removing a rule that subscribers are already depending on.