Distinguishing Between Primary Workflow Rules in Create Scripts

3 minute read time.

In Sage CRM it is possible to have multiple workflows created for an Entity. For example we may have one Opportunity workflow that is used by a one team for a particular type of sales opportunity and another workflow that is used for a different type of sales process.

The different workflows may have different primary rules and so start their process in different ways as shown in the image below.

The two different workflows are defined in meta data within the workflow tables.

The workflowrules table holds the definition of the workflow rules within different processes. I can see the rules that start the different opportunity workflows in my system by running the following query in the SQL Management Studio.

[code language="sql"]
select * from workflowrules where WkRl_RuleType = 'new' and WkRl_Table = 'opportunity';
[/code]

In my system I have two opportunity workflows with two primary workflow rules.

  • New Opportunity, wkrl_ruleid = 50
  • Create Oppo, wkrl_ruleid = 10160

In Sage CRM if I start to create a new Opportunity by right mouse clicking on the New option in the main menu and selecting "New Opportunity" I will create a screen that follows the definition of the workflow rule.

If I then right mouse click on the screen and view the properties I will find the URL that has been used looks like this:

http://stl00539/crm/eware.dll/Do?SID=72871909626702 &Act=1190 &Mode=1 &CLk=T &Key27=50 &trid=454 &newbtn=t &T=New &Key0=4 &Key4=4

The corresponding URL for the workflow rule "Create Oppo" looks like:

http://stl00539/crm/eware.dll/Do?SID=169514101526701 &Act=1190 &Mode=1 &CLk=T &Key27=10160 &trid=482 &newbtn=t &T=New &Key0=4 &Key4=4

Imagine the business has a requirement that certain fields not covered in the workflow actions should be set to different values depending on which workflow is used. E.g. oppo_source is held in the OpportunityDetailBox and needs to have a different default value set depending on whether the "New Opportunity" rule or "Create Oppo" rule is followed.

We can use the idea that the query string contains Key27. (See the article Long List of Key Values for Sage CRM)

Key27 contains the WorkflowRule ID.

Therefore in the OpportunityDetailBox we could add a create script to the oppo_source field that referenced this like

[code language="javascript"]
if(Values("key27")=='50')
{
DefaultValue='Phone';
}
[/code]

But there is a problem. The URL that contains the Key27 values is not always consistent. For example. If a user clicks starts the New Opportunity action but then clicks away onto the Find action on the main menu, then clicks back the New button they will return to the last New screen screen they were using the but the underlying URL will now look like

http://stl00539/crm/eware.dll/Do?SID=72871909626702 &Act=166 &Mode=1 &CLk=T &Key0=20 &T=New

This does not contain the Key27 name/value pair. It looks like we can't find out which workflowrule is being used.

In reality we can because we can use a technique similar to the one used in this article "How can I get the SID in Serverside scripting?"

That article used the trick that the CRM.URL() method can be used to rebuild the keys for the particular context. The CRM.URL() method is normally used to build buttons in ASP pages or to redirect pages to other locations but it can be used in serverside code to retrieve the information we need.

If you use a simple script like

[code language="javascript"]
Valid = false;
ErrorStr = CRM.URL(166);
[/code]

Then this will build a message on the screen that shows the context that the method understands that system to be using.

E.g.

/crm/eware.dll/Do?SID=169514101526701 &Act=166 &Mode=1 &CLk=T &Key0=20 &Key27=50

Note: The Key27 information will always be returned within this URL if you are entering the screen built by the primary workflow rule.

This means that the URL returned by the CRM.URL() method is a reliable indicator of context and it can be parsed to return the key information we need to identify the workflow rule used.

For example the create script can be changed to

[code language="javascript"]
function getKey(x)
{
var strPath = CRM.URL(166);
var arrayFullKeys = strPath.split("?");
var arrayKeys = arrayFullKeys[1].split(" &");
for (var i=0;i
{
var arrayValue = arrayKeys[i].split("=");
if (arrayValue[0].toLowerCase()== x)
{
return arrayValue[1];
}
}
}
Valid = false;
ErrorStr ="SID="+getKey("key27");
[/code]

We can then can then change the original code for the oppo_source create script to look like

[code language="javascript"]
function getKey(x)
{
var strPath = CRM.URL(166);
var arrayFullKeys = strPath.split("?");
var arrayKeys = arrayFullKeys[1].split(" &");
for (var i=0;i
{
var arrayValue = arrayKeys[i].split("=");
if (arrayValue[0].toLowerCase()== x)
{
return arrayValue[1];
}
}
}
if(getKey("key27")=='50')
{
DefaultValue='Phone';
}
[/code]

  • Michele

    The Details field and the other fields in the Opportunity Detail Box show up on the Opportunity Summary. These are common fields for opportunities. But different opportunity workflows may mean that certain fields don't need to be displayed. You could replace the Summary screen with different ASP or .NET pages but that would probably be overkill. Instead you can hide (or collapse) fields you don't need in different circumstances. Have a look at the client side API. This allows you to select multiple fields all at once and then make them disappear from the user interface.

  • Jeff:

    Since we are able to have multiple opportunity workflows are we able to change the details box that is used for each of those workflows? Since the details can be very different from one oppo to the next, I would like to use a different detail box rather than trying to hide fields depending on which oppo workflow is used.

    Do I have to create a new asp page? If so, is there an example of one so that I get all the other blocks/panels on the screen?

    I feel like I might be making it harder than it actually is. Therefore, any assistance that you can provide would be greately appreciated.

    Thanks!

  • Jeff...

    I was able to figure out what "trid" means by looking in the Workflow tables. I found a table called WorkflowTransition and then in there I found a filed called WkTr_TransitionId which matching the number I am seeing in the Url for &trid=.

    Once I knew it was Workflow Transition, I searched Workflow Transition in the community and found your article called..."How can we tell in SQL which are valid next workflow transitions?"

    From reading the article and looking at our own system, it looks like that ID might represent the actual "location" of the rule on the workflow diagram.

    It also looks like this number changes if you change the workflow.

    I am wondering if I am looking at what that id means correctly.

    If I understand your article, you are describing how to get the "next" rule in the workflow as it is stored in the database based on where you are "at" in the workflow.

    I am asking about that piece of the url because I was thinking about using it to determine what displays on my screen. If I am understanding the system, that would work as long as I NEVER edited the workflow. Based on what I think I am seeing it is not a reliable value because of its likely hood to change.

    I know that I can add my own parameter. However, it is not working for me, the value keeps coming back as "undefined". Therefore, I am working trying to figure why my code is not reading it. That may end up as another post! :-)

    Am I understanding the Workflow Transition ID correctly? Thanks!

  • Jeff..

    This article is very helpful!!! :-)

    In the URL I see "trid". I searched the community for its meaning...but have not located it. Can you please tell me what "trid" represents?

    Thanks!!