CA PPM - Processes: a way to standardize them a little bit more

Blog Post created by anggi01 Employee on Dec 7, 2017

We experienced a slight different way to implement processes, and it has been tested with three clients so far (Assicurazioni Generali, NEXI, BPER).


This is the idea, basically:

a workflow is all about the motion of an object in a path: depending on the stage, some roles can perform given actions which could basically be a promotion to the next stage or a demotion back to an earlier stage.

other than that, a workflow should check if the data is correct to perform that action (you can approve a demand if you miss some information), send emails, and perform other stuff when the action has been done (you may need to execute a process, lock a field, or even integrate another system: see three layer integration).


This is then how we implemented:

  • The object for which you must implement the workflow should have three fields:
    • phase and state: which determines the position in the workflow
    • action: which is the possible action an user could do, based on phase and state and his role
  • an Object (we usually call it Monitor) that you fill these data:
    • starting phase and state
    • target phase and state
    • action
    • role which could perform the action
    • plus several other field depending on your business needs (such as standard message you want to send as an email to the stakeholders when the action is performed, help on line that the user can see in the object edit form when the object is in that
    • pre-conditions: pieces of parameterized SQL code to check if the object could be processed by that action
    • post-conditions: again some SQL code, or even workflows
  • the workflow than:
    • reads the instance of the monitor object, corresponding to that action
    • executes the pre-conditions, and returns a message if the precondition is not met
    • changes the phase and state of the object, when the pre-conditions are met
    • register an instance in a sub-object with the information about when who and why performed the action
    • triggers the post-conditions.


these are the outcomes of this approach so far:

  • the workflow is stable: you basically work on the monitor object, or on pre and post conditions.
  • the workflow is pretty readable: you can export the Monitor to share all of its information, including controls (pre and post)
  • the Client is able to understand what's going on much more than with other approaches.