APEX: Workflow Development Practices - Part I
Sydney Nurse
I’d like to begin a social dialog around APEX Workflows, specifically around better development and runtime practices. This will be a learn as we go and longer term exercise as we implement & discover more effective ways while working with this feature.
A Social Dialog in that I wish you, the reader, to share, through posts, your findings and evaluations based on anything previously shared or discovered as you’ve implemented solutions.
If you are unfamiliar with APEX’s Workflow feature, I would recommend to start here:
Simplify Business Process Management Using APEX Workflow - Identify Business Steps
Doc. v23.2 => About Workflows (current documentation has added content for added features)
In its basic form a workflow it is a sequence of activities, executed in order or directed by decision point. A distinguishing factor is the involvement of human actors, across line of business roles/groups with the ability to automate manual tasks.
I will preface that I am not going into the finer points of process flow optimisation, rather I want to start my journey on how to approach development of a Workflows in APEX.
About this Post
In this post, I’ll try to contrast Workflow Activities to Human Tasks & Page processing. Each of these components provide processing, synchronously or asynchronously, within a user’s session or out side of an APEX session, on state transition or next in sequence.
Why these? Well, in my humble opinion this aligns with the journey that APEX has gone through so far. Page processing, Human Tasks, and adding Workflow.
Let’s explore these items over the next few minutes
APEX App Processes
APEX offers many processing options, from Application & Pages Processes (Pre-, Post- Rendering, and Page Submission), Plugins, and now Human Task Actions, Automations and Workflow Activities.
Only the latter two stand out, Automations and Workflow Activities, as they are executed outside the User’s session and life span can be across many user sessions.
For today I will only contrast Page, Human Task Actions and Workflow Activities.
Page Processes & Execution Chains
APEX supports many process types, see => About Page Processes, including code execution, API invocation, creating Human Tasks and starting new Workflows.
Page Processes are ordered sequence of processes steps. Execution Chains allow us to define a grouping of process steps and has the benefit of background processing, but care should be taken with the sequence numbering and other processes defined on the page.
The sequence how ever is only seen by the developer with execution driven by server side conditions or authorization scheme. This is the extent of conditional branching and outcomes or step states would need to be manually coded for.
Use page process operations that are bound to the users session and should complete during the page’s lifetime. That stated execution times should be short, leaving the impression of a highly performant and fast application.
The trigger of page processes are defined by and in the page and typically not exposed to external invocation.
Page processes can only operate on data accessible from within the user’s session. i.e. Data in tables, items added, updated, calculated while the user is logged in and in the session state. If a user runs a pages several times selecting different records for form pages, then the values are unique to that version of the page in time.
APEX provides different processing points on a page both Pre & Post rendering, after submit and processing.
Page processes should be documented externally, though comments are supported, proper documentation should be used to describe the page processes and communicate with both technical &non-technical staff.
Page processes logging is written to the user’s session log when debugging is enabled.
Human Task Actions
Human Tasks are defined within an application as activities to be completed by a specific user or users in a group or having a certain role. These are the task’s participants.
Human Tasks are defined by developers and have instances of the task at runtime containing its variables, parameters and actions defined at the point of time it is created. Only instances of tasks transition between the lifecycle states and execute task actions.
Task Actions are defined within a Task and mainly driven by the Task State. The state is defined as the current location of the task in the task lifecycle.
When a task transitions into a lifecycle state you may define a action. Actions are triggered by the events on the task that also include change of comments, priority, parameters. Human Task owners & Business Administrators can also set the tasks state.
Task Definition Actions - Possible events that can happen when specific criteria are met. Available actions are:
Claim
Complete
Delegate
Update Comment
Update Priority
Update Parameter
Release
Cancel
Create
Request Information
Submit Information
Before Expire
Expire
Task Actions are limited to executing code, sending email or push notifications, and server side Geo-coding.
Task Actions can only operate on data accessible from within the user’s session. i.e. Data in tables, items added, updated, calculated while the user is logged in and in the session state.
Actions are ordered by sequence and conditions can be placed on task actions to further control execution.
The order of execution is not a straight line but is dictated by the task’s lifecycle and a sequence can be applied to multiple actions for a single state transition or on an event, and the same cation applies to actions having the same sequence number.
The sequence order is only visible to the developer and like page processing, should be documented using external means.
Logging can be enabled for Task Actions but are included in the user’s session debug logs.
Workflows Activities
I’ll start bottom up with Workflows with the documentation, which is still important to have but workflows and business process diagrams are visual and in themselves part documentation. The visual element simplifies conversations and reduces much confusion between developers, technical analyst and business process owners.
The workflow diagram provides insight into the flow of execution but not the activities themselves. Workflow activities combine the various process types supported by pages that are relevant to background process (not UI components), ability to check the states and outcomes of Human Tasks, and has its own runtime lifecycle, though typically does not influence the flow of execution.
The workflows states and transitions are distinct and separate from the workflow and apply to all workflows, similar to Human Task states and transitions.
The order of execution in a workflow is defined by the order and connection between its activities which are its logical steps. Similar to Human Tasks the order of execution is not a straight line but based on the connectivity between activities and decisions based on activity states, business logic or other influencing variables and outcomes referenced by the workflow.
The decision points or branches within a workflow allow for process automation, combining human interactions with system output to determine the next step or sequence applied to the current instance of the workflow.
The workflow instance is the runtime version of the workflow, similar to human tasks. Similar but different as workflows operate outside the user’s session. Workflows operate on data accessible from within tables, variable and parameters, responses, outcomes and states from activities.
Workflows also have associated versions and a state of In Development (available within a developers session), Active (Production for normal user session), inactive (no longer useable but does not affect instances). When started a workflow’s instance is based on the version and will run under that version of the workflow for its lifespan.
A major difference between workflows, pages and human tasks is that changes to activities, flow changes to activities, still to be executed or faulted and can be retried, or added along the to be executed path, will be reflected in the workflows execution.
Workflow Visibility
Workflows diagrams and activity execution flow can be displayed to the end users.
This provides insight into the execution and timing of tasks without the need to involve a developer.
Workflow instances and activities in a Workflow, have their own state, some can be used to drive workflow decisions but mostly states are seen by owners and administrators of the workflow instances.
Where Should You Process Your Process?
Seasoned consultants and developers will always answer; “It Depends”, which is almost always true.
After defining the end to end process flow and coming to the decision that it is appropriate to deliver using APEX, consider the interaction required for the process flow.
Is this an atomic user session bound process flow?
How many users, groups or roles need to participate?
How many steps are involved in the process flow?
What is the lifespan or the process flow?
etc.
A clear case for Page processing is that the flow relies solely on a single user’s session and should complete during the pages life time.
Solely Human Tasks would suite a single request that needs to be fulfilled by an individual, group or role. The task should not have other dependencies pre or post though this could be taken care of during the created or completed states.
Workflows shine for long running processes, can require activities of multiple users, groups, and/or roles, or more complex automation scenarios.
Conclusion
Several options exist to handle end to end process flows, including automations (not covered), Page processing, Human Tasks, and Workflows.
Processing points, and states can aide in controlling when processes are executed while some states are there to manage or informational only.
Try to keep the implementation as simple as possible even if the future could require change, say adding a multi-level approval process, if only one group needs to approve, then use a single Human Task vs. adding a Workflow. If a process is a few session dependant steps but take some time to complete, consider using process chains and background processing.
Account for your end users business context and concerns, say they want to have overall visibility and management of the process flow, then perhaps moving page processing to a workflow would be appropriate over creating custom pages and setting up audit tables to track the processes.
Tell me what you think by commenting and linking your post on tis one.
Subscribe to my newsletter
Read articles from Sydney Nurse directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Sydney Nurse
Sydney Nurse
I work with software but it does not define me and my constant is change and I live a life of evolution. Learning, adapting, forgetting, re-learning, repeating I am not a Developer, I simply use software tools to solve interesting challenges and implement different use cases.