20.12 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 If you configure an error connection, you can avoid this message. In the settings for the error connection, select 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 | Why are active workflow instances suspended after reimporting or moving the application 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. A workflow administrator must resume these suspended instances either through the Workflow Console or by using the APEX_WORKFLOW.resume() API.
|
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 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: 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 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 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 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:
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
|
Parent topic: Managing Workflows and Tasks