Previous Next JavaScript must be enabled to correctly display this content

## 20.13 Frequently Asked Questions

Reference a list of frequently asked questions for workflows.

Workflow Designer

Topic | Question | Answer
--- | --- | ---
Parallel Flow Activity Deadlines | How do I configure my workflow to continue running after a parallel flow activity reaches the deadline? | You can model a Timeout transition together with the parallel flow activity. This allows the workflow to continue after the deadline of the parallel flow activity is reached.
Parallel Flow Activity and Workflow Variables | How do I manage updating workflow variables in multiple branches of a parallel flow activity? | You can manage workflow variables in a parallel flow activity by introducing one or more activity variables for each branch of the parallel workflow. The variables are updated in the branches. Once the parallel activity is complete, another activity (for example, Execute Code) determines which of the activity variable values becomes the new workflow variable value. Tip: There are no limitations regarding workflow variables in parallel flow activities. However, Oracle does not recommend modifying the same workflow variable in multiple branches of the parallel flow activity as this may result in inconsistent behavior.
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
--- | --- | ---
Application Reimport/Migration | What happens to workflow instances when the application is reimported or moved from a development environment to a production environment? | During application reimport, running instances of workflows are suspended to ensure that no workflow instance inadvertently moves to a faulted state due to temporary unavailability of the workflow definition. When the application reimport is finished, the workflow instances automatically resume. Manual intervention is not required.
Multi-Tenant Workflow Console | How does the Workflow Console segregate across tenants? | The Workflow Console honors the APEX session tenant ID and only shows workflows for the tenant.
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? | The tasks move to a Canceled state if the associated workflow is terminated.
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 approval task activity. 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? | Yes. Use the Invoke Workflow activity type. See Adding an Invoke Workflow Activity.
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 - Resume | Can I resume workflows at any activity? | Yes, workflows can be resumed at any activity, but this requires additional developer configuration. For more information, see Resuming Suspended Workflows at Any Activity.
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;

Parent topic: Managing Workflows and Tasks