Sage CRM 2019 R2: Multiple workflow paths for the same entity

Hints, Tips and Tricks

Technical Hints Tips and Tricks that cover customization and development using Sage CRM. API usage and coding are covered.

Sage CRM 2019 R2: Multiple workflow paths for the same entity

  • Comments 2
  • Likes

This article has been prompted by a question from a customer. They need for their users to capture Opportunity 'quick facts' to start the sales process. In their case, their contacts may wish to buy a 'product', a 'service' or a 'combined' solution. Depending on the prospect's interest then the sales process needs to go down a distinct path with other information needed to be captured. And it may be possible to 'jump' to another workflow later on.

I've assumed that for this article you know a little about Sage CRM's workflow processes. The Sage Support & Training YouTube channel has some good short videos that explain workflow.

We have perhaps 3 basic options for the workflow design at this point.

  • Single Branched Workflow Process
    • This would start the workflow with a single Primary Rule that governs the initial creation of the opportunity. The workflow would then branch depending on the data that was captured. This approach could become very complex very quickly.

  • Separate Workflow Processes (Primary Rules)
    • This would present a user with 3 separate options to create and manage the opportunity. But it would require the user to have foreknowledge of the process that needs to be followed.
  • Separate Workflow Processes (Transition Rules)
    • This option doesn't use workflow to create the opportunity but once the opportunity is captured with the key information then the opportunity can be attached to a particular workflow.

Sage CRM's supports the idea of branched workflow but in this case, where key information needs to be quickly captured and that key information needs to be used to determine the workflow it is most appropriate to use 3 separate workflows.

This approach does not use a 'primary rule' to start the workflow but rather 3 separate workflows that each start with a Transition Rule. This means that the data would be captured using the basic New Opportunity page. The screens that make up this page (OpportunityFilterBox, OpportunityDetailBox etc) can be simplified to capture on the key information that the customer needs.

Once the opportunity record is created and saved it is not yet attached to a workflow process (The oppo_workflowid field would be null). But transition rules within the workflow definition can be linked to the 'start' state and so be able to be visible to a user looking at an opportunity record not yet associated with a workflow.

What that means is that potentially 3 separate buttons could appear on the new Opportunity Summary screen inviting the user to follow either the 'Software' or 'Services' or 'Combined' sales workflows. (And example of this is provided in the default Opportunity Workflow that causes Accept or Reject buttons to appear for new opportunities converted from Leads).

But if the aim for the customer is to only be presented with a single option then this could be done because the transition rules have a JavaScript condition box that can look at the data in the record and see whether the conditions that allow the button to display are satisfied. So if in the 'oppo_saletype' field the user has selected 'Software' then only the workflow button for Software Sales workflow would be displayed.

It is possible to jump workflows so if the user has made a mistake and it turns out that after further discovery the prospect needs a 'Combined' solution then this can be made to reset the workflow and go down another path.

  • A great article. I tend to go down the route of having one primary rule and base the next level on a JavaScript Condition - as you mentioned, as this keeps the user within one main workflow which is then easier to jump around if the scenario turns out to be something completely different.

  • Thanks Matthew.  I am slightly hesitant about recommending a single branching workflow because of the potential complexity in maintenance - I worry about system administrators getting lost in the different processes.