Because of the nature of Workfront Fusion, service outages have unique implications for active FLOs, depending on how each FLO is initiated.
For more details on specific incidents that could affect your FLOs, check our status page at trust.workfront.com. Contact Workfront Support for further assistance.
The following table shows how each type of FLO is affected by a service outage:
Affect during a service outage
|Monitor FLOs||Triggered when a scheduled check finds new application data (such as when a new task is created in Workfront). Each Monitor FLO tracks when the last check was made and what the last new record was. Data is not lost when a scheduled check is missed during an outage because the new data is detected by the first check after the outage. The default for monitor FLOs is to check every 5 minutes, so an outage usually results in only a short delay to processing this type of data.|
|Real-time (webhook) and API endpoint FLOs||Initiated directly by another application, including Workfront, through real-time triggers. If there is a service outage at the time of the call, the result depends on how the calling application recovers from getting no response. Like other applications, Workfront automatically retries calls again later so they succeed with the call when Workfront Fusion is back online. Workfront is designed to retry sending events when the Workfront Fusion service is unavailable and, as such, events are processed by Workfront Fusion after the service fully resumes. For more details about event subscription retries in Workfront, see "Understanding Event Subscription Retries."|
A FLO that runs on a fixed schedule misses any scheduled runs during a full outage. Because of this, you might need to manually run the scheduled FLO after an outage is complete.
|Form FLOs and FLO Pages||Unavailable during outages.|