top of page

APEX Workflows - tips, tricks & lookouts

  • Writer: Clark Pearson
    Clark Pearson
  • 1 day ago
  • 2 min read

I've had a play around with a really simple APEX Workflow:


Diagram Builder workflow on a gray grid: icons and arrows link Send approval email, Set CR Awaiting Approval, Approval Awaiting, Set CR Approved

Here are some points to bear in mind when working with one:


  • Workflows and Tasks run in background scheduler jobs with no APEX session. You cannot therefore use eg. :APP_USER in static values, say, as a variable. You would need to pass :APP_USER in as a parameter to the workflow from the page process.


  • If you want to run something in a scheduler job for doing something with a workflow, you need to call apex_session.create_session(..) with the appropriate user id.


  • The APEX built in packages that provide pipeline table functions, PTFs, to pull workflow and task info default to p_application_id => NULL => ie. all apps! This means that workflows created in one app can be viewed and amended in another 😮


  • When APEX auto-generates pages and regions using those PTFs, it includes a commented p_application_id => :APP_ID, so uncomment. The docs talk about enabling sharing so that you can link between apps; I suppose it comes down to whether your apps have strong links between them, but in my experience, apps have tended to be self-contained.


  • To activate a workflow in order that you can instantiate one and progress it, there must be an Owner defined. In order to add a Workflow Owner, expand the workflow in the left pane, right click the Participants, add one, and choose that Type.


  • To see workflow instances instantiated by others, there must be at least one admin for the workflow, and you must be logged in as one of those users. Follow the steps to add a Workflow Owner above, but choose Administrator, instead. Note next:


  • Conflicting info regarding Workflow Admins has been observed. In two online sources [Doc link (point 4b); Blog link (search for 'SQL Query')], it is stated that you can use a SQL query to define who is a Workflow Admin, and it can return multiple rows. But the help in the Developer Console for a SQL query states: If more than one row is returned then the value of the first row is used. Consequently, until this is understood better, include separate Workflow Admin Participants for the workflow – or let us know what you've discovered. My experience strongly suggests the Dev Console help is correct and only the first row is used.


  • After amending a workflow/task, always start a new workflow instance from scratch again: for example, adding a Workflow Admin to the Workflow Definition, doesn't give the newly added Admin rights over workflow instances already started. This might not be necessary in all scenarios, but if in doubt, recommence a workflow instance before assuming the change just made hasn't worked.


  • Remember, these workflows operate in background Scheduler jobs*: when the workflow commences, rights are evaluated at this snapshot in time, not in real time as the workflow progresses. (*Even when one is instantiated on a page process.)


  • Finally, you can't query those PTFs mentioned above from SQL Workshop (you always get NDF, since there is no application user attached to the SQL Workshop environment). Instead, you will need to include a temporary or commented-out/in report region in your page to debug what you can actually see.


If this was useful, like the post, and follow us on LinkedIn!

bottom of page