20.13 Frequently Asked Questions

Reference a list of frequently asked questions for workflows.

Workflow Designer

Topic	Question	Answer
Switch Activities	For more complex conditions, should I use a true/false type switch and a PL/SQL expression or function body that returns a boolean result?	You can create more complex conditions by using an if-elsif-else switch, where there is flexibility to specify different types of conditions on each of the switch branches. The true/false type switch is the simplest condition because the only available results are true, false, or null.
Wait Activities	Why can't I see the deadline section for wait activities in the property editor?	Wait activities have their own timeout attributes. The generic deadline section is not visible.
Error Connections	How can I effectively use error connections in my workflow model?	Consider an order management workflow with an Invoke API activity that fetches the order number from the ORDERS table before proceeding to the next activity in the workflow. If the query returns no records, the Invoice API activity throws a no_data_found exception, and the workflow status transitions to faulted. If you configure an error connection, you can avoid this message. In the settings for the error connection, select = as the condition, and the SQL Error Code for no_data_found (01403) as the value. To handle this error, you can set up an Invoke API activity to create the missing order and add it to the ORDERS table. This method efficiently handles the error, and prevents the workflow from going into a faulted state.
Workflow and Activity Variables	How do I decide when to use workflow variables and when to use activity variables?	Workflow variables are alive through the lifetime of a workflow instance. Their values can be accessed and altered by all the workflow activities. Activity variables only live during the execution of a particular activity. Typically, activity variables fetch additional data that may be needed by the activity during its execution.

Workflow Runtime

Topic	Question	Answer
Tasks and Workflows - Deadlines and Expiration	When a workflow contains a task activity with a deadline specified in the workflow and a deadline specified in the task definition, which deadline is honored?	The workflow activity deadline gets precedence over the task deadline. If there is no workflow activity deadline, the workflow uses the deadline in the task definition.
Tasks and Workflows - Deadlines and Expiration	Tasks can expire and be auto-renewed. Does this also apply to tasks created using workflow?	At runtime, if the task fails to complete by the due date, the expiration policy in the task definition activates, and the task is automatically renewed or expired accordingly. If the expiration policy in the task definition is NONE, the task still expires because it is a workflow-generated task, and it cannot remain active while governed by workflow timeout. Once the task expires, control goes back to the workflow engine, and the engine follows the timeout connection in the workflow definition. If there is no timeout connection, the workflow transitions to a faulted state.
Tasks and Workflow - Deadlines and Expiration	If a task is created using workflow, can the Business Administrator of the task manually renew or update the due date?	No. Tasks created by a workflow can only be auto-renewed based on their expiration policy settings. The business administrator cannot manually renew or update the due date of a task because the due date is governed by the workflow timeout.
Tasks and Workflow - Errored or Canceled Tasks	What happens to the workflow if its task becomes errored or canceled?	When the initiator or business administrator cancels a task, the workflow runtime engine receives no task outcome, and continues executing the next activity in the workflow. If the next activity in the workflow is a switch based on the outcome of the task, the switch activity transitions to faulted because the task-based workflow activity has no outcome. When a task transitions to errored, control returns to the workflow, which transitions to faulted. The workflow administrator can retry a faulted workflow after fixing the underlying cause of the error.
Tasks and Workflow - Errored or Canceled Tasks	What happens when a workflow is terminated while its tasks are still active and not yet completed?	Currently, the tasks remain active and do not automatically cancel. However, if a user completes the task, the workflow does not progress since it is already terminated. This is a known issue in the current release.
Tasks and Workflow - Using Approval Task Outcomes in Workflow	How can the outcome of an approval task defined as a workflow activity be used by other activities in the workflow?	For every approval activity in a workflow, two associated workflow variables exist: TASK_OUTCOME and APPROVER. In the activity settings, you can set the task outcome and approver attributes to these variables. After the actual owner completes the task, the workflow runtime engine completes the activity and sets the workflow variable TASK_OUTCOME to approved or rejected. The activity also sets the APPROVER variable to the actual owner. Subsequent workflow activities can use these workflow variables. For example, set a switch activity that follows the human task activity to Check Workflow Variable, specify the variable as TASK_OUTCOME with a condition of = APPROVED or = REJECTED, and use that variable to branch the workflow. Note: If there is more than one approval task activity in the workflow, the subsequent activities do not have workflow variables automatically created for them. You can choose to re-use the same workflow variables to store the task outcome and actual owner or you can manually create new workflow variables if each human task activity outcome must be stored in a different workflow variable.
Tasks and Workflow - Using Approval Task Outcomes in Workflow	I accidentally rejected an approval task instead of accepting it. Can the workflow administrator fix this in the associated workflow?	Yes, the workflow administrator can fix this if the workflow has a wait activity right after the human task activity. The suggestion duration of this activity is two to five minutes. After an approval task is rejected, the TASK_OUTCOME workflow variable value is REJECTED. During the wait activity, the workflow administrator can suspend the workflow from the Admin Console Details page. The administrator can then expand the variables section on that page, click Edit next to the TASK_OUTCOME variable, and manually update the value to APPROVED. When this is done, the workflow administrator can resume the workflow. Note: Only workflow administrators can update workflow variables, and only when the workflow is suspended or faulted.
Workflow Subprocess	Can a workflow be used as an activity in another workflow?	This is not currently supported.
Workflow - Retry	Can auto-retry be configured for workflow activities?	No. Workflow activities that transition to faulted must be manually retried by either: the workflow administrator clicking Retry in the Workflow Console Details Page calling apex_workflow.retry() and passing the workflow instance ID Retrying a workflow always re-executes the activity where the workflow faulted, and then continues the rest of the workflow execution chain. There is no limit to the number of times a workflow can be manually retried.
Workflow - Retry and Resume	What is the difference between Retry and Resume for a workflow?	Retry is only applicable to faulted workflows, and can be performed by both the workflow administrator and the workflow owner. Resume is only applicable to suspended workflows, and can be performed by the workflow administrator.
Workflow Versions	My application has a workflow with two versions: 1.0 is the active version, and 1.1 is the development version. When I run the application from App Builder, can I specify in the workflow page process which version of the workflow APEX uses?	The workflow page process only takes the workflow definition as input, not the version. Running an application from App Builder implies the application is running in a developer session, and APEX uses the development (1.1) version of the workflow. If you run the application without any active developer (App Builder) sessions, then APEX uses the active (1.0) version of the workflow.
Workflow Versions	I am running the application from App Builder. My application has a workflow with only one version, 1.0, which is in development. When I run the application from App Builder, Suspend and Edit link for workflow variables are available for both the workflow owner and the workflow administrator. However, the documentation mentions that only the workflow administrator should have access to these operations. Why can the owner see them?	When running the development version of a workflow, APEX does not perform authorization checks. APEX only performs authorization checks for the active version of a workflow.
Workflow Versions	While running an application containing an active workflow version, I started a few workflow instances. Since then, I have added two new workflow owners and one new workflow administrator to the workflow. How can I reflect the new participants in the currently running workflow instances?	Call apex_workflow.refresh_participants from a valid APEX session. This API re-evaluates the participants in the workflow definition and updates the currently running workflow instances.
Workflow Versions	I have moved my development workflow version to active. I want to delete all the workflow instances I created while the workflow was still in development. Is this possible?	Yes. Call apex_workflow.clear_test_data, passing the application ID and the static ID of the workflow definition. This deletes all workflow instances created while running the development version of the workflow.
Workflow Versions	I have moved my development workflow version to active. I had a previously active version, which is inactive now. What happens to the workflow instances created based on the previously active version? Are they terminated or deleted?	No. The workflow instances created from the previously active workflow version all continue to run until complete. However, you cannot start any new instances based on the previously active version of the workflow. All new workflow instances are based on the current active workflow definition.
Workflow Debugging	My workflow instance faulted at an activity. I did not set any debug level for the workflow version. Can I still enable debugging and retry the activity?	Yes. Call apex_workflow.set_log_level(), passing the workflow instance ID and the log level you want (apex_debug.c_log_level_app_trace). This enables logging for the specific workflow instance. You can check the log entries by querying: select message from apex_debug_messages where workflow_instance_id =workflow instance ID order by message_timestamp asc;