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

    If you need to make big changes to the main panel of Opportunity Entry screen, consider using an ASP or .NET built page. A primary rule of a workflow can call an ASP page.

  • Jeff:

    Thank you for your response. You would make a great politician! :-) (lol)

    I apologize but I do have one additional question. Is it possible for me to get the additional panel to show up during the oppo creation (Act = 1190). Most of the examples in the community show how to add a panel when the screen is in "view" mode not "edit" mode. Therefore, I am wondering if it is possible to do it in "Edit" mode.

    Your assistance is always appreciated!

    Thanks!!

  • Michele

    Try and keep your page as simple as possible. And then document all your assumptions and actions so that when you (or another) return to this in a couple of years you will know exactly what you have done and why you have done it.

  • Jeff:

    Thank you for your response. It was helpful as always. After thinking about this and refreshing my memory on working with summary screens, I think I am going to leave the detail screen box alone and only have common fields on that panel but add another panel for those fields that are different between workflows and use Key27 to determine which additional panel to display for the different workflows.

    I do understand that I could leave the fields on the detail box and add code to each of the fields as recommended above. However, I am trying to make it easier for the individual that is adding the fields to the screen block during implementation and in the future. It seems easier to give them a block for the different workflows and allow them to add to or remove which ever fields they want to display on the screen. Since there are three different oppo workflows, they won't have to worry about entering code as they add and remove fields.

    Do you see any flaws with this approach?

    Your assistance is greatly appreciated!