Workflow Automation and IPM Custom Actions

IPM Provides for extended use of workflows and dialogues. Although the standard approach of selecting an appropriate on-demand workflow from a menu is functional and provides a fair degree of flexibility from a Users perspective it means they need to click more and know more about what is going on. IPM provides some standard features to allow the automation of workflows not provided in the standard CRM Product.

Dialogues

Dialogues area one area that IPM has targeted to provide additional automation. After installing IPM, every entity will show an Orange "Process" button on the tool bar. This does not signify that there is a process or Dialogue available to run, but merely provides a way to automate the running of a default Dialogue. It might be suggested that to only provide for one is very limiting but if you need more than one, then run additional child dialogues from the main default dialogue.

In order to make a Dialogue a default Dialogue it the simple trick is to name it either the same as the associated entity or name it using the same Label as that which has been assigned to the entity. For Example you could name a Dialogue either "IPM_PurchaseOrder" or "IPM Purchase Order" and either naming conventions would result in the successful running of the target dialogue. The point is the user just needs to learn to press the same button on any screen to get some sort of prompt as to what next to do.

Workflows

With many of the IPM Documents it is a fairly normal concept that once a document has been sent then other things should happen as a result. With this in mind IPM has automated the running of workflows after any of the orange print/send action buttons are utilised. These buttons include "Create PDF" and "Create Email". So by either clicking the Create PDF button or clicking the Create Email button will automatically run any workflowed named in after the entity, so specifically ipm_entity. The process will automate any number of similarly named workflows so you may have several workflows you want to action in which case you could put them all together in the one workflow or simply have them named identically and the system will run them.

 

IPM Workflow Actions.

IPM Global has a number of workflow activities to handle various tasks not addressed through standard CRM workflow actions.

“Get Primary Entity Info” workflow activity.

The “Get Primary Entity Info” activity retrieves context information about child records in the IPM structure. For example if the current workflow parent is the Purchase Order record this workflow action will retrieve information about the Job record so that the Project manager can be retrieved as well as contextual information. Its primary function is to retrieve the URL for the current record to allow this information to be included on emails.

 

 

“Decode Contact” workflow activity

“Decode Contact” workflow activity is an activity that allows the Primary CRM information to be retrieved from an IPM Contact or a Job Contact. Unfortunately in most situations it is not possible, nor is it necessary, to determine what sort of entity is the CRM entity, be it User, Account or Contact. If you use this action to drive an workflow email simply include all three alternatives in the Email field as only one will resolve to an email address as in the following image.

Decode Contact is often used in conjunction with the Get Primary Entity Info for retrieving the Email address to the Project Manager

 

“Get Job Contact” workflow activity

This workflow action will allow the checking for the existence of a job contact and if the job contact does not exist it will create one. This can be used where Routing records have been setup to automatically add to job documents or are manually added to a document and they are required to be added as Send to contacts. Routing Records are based on IPM contacts whereas Send To records are related to Job Contacts so a workflow that uses this action this way will facilitate the use of the IPM Contact multi-select to automatically populate the Job Contact table.

“Process Child Records” Workflow Activity.

Although we have tried a number of fairly advanced components from the codeplex site there has always been an issue with workflows losing context. There is a very useful component we identified on the codeplex site that allows the running of workflows on child records. This, although extending workflow functionality considerably did not answer the situation where we needed to build child record structures from related structures. This has led to the development of the IPM Global “Process Child Records” custom workflow action. This advanced action provides significant functionality that could previously only be executed using plugins.

 

 

1. The first facility offered is the ability to run a workflow on a child record. To achieve this put the value of the parent identifier in the parent 1 field. If the current workflow parent record is the

parent to the child records to be processed no Parent 1 value needs to be identified. This identifier can be the primary identifier for the current record or it can be a lookup field on a related record. In the example the primary record associated with the workflow is the Site Diary/Daily Report and the Parent 1 “ipm_jobid” is indicating that the child records to be processed are off the Job Record. The Relationship 1 value identifies the child table by specifying the link to the Job Record which in this example is ipm_ipm_job_jobtask.

In Filter 1 a filter can be identified to allow only particular child records to be selected to run the workflow for.

In workflow 1 specify the name of the workflow to run.

If all the workflow is required to do is run child workflows then only these 4 parameters need to be completed although the first and third parameters are optional.

2. The second use for this workflow is to build a child table based on relationships. Parent 2 can be completed if the Parent Record is not the current workflow parent record. In this example the Site Diary/Daily Report is the record that is to own the child records to be created so no parameter is required in the parent 2 field.

The Relationship 2 value identifies the child record set to be added by specifying the link field for this child record set.

Avoid Duplicates allows the checking for the existence of the child before adding. If the child exists an update will be done, otherwise the child will be added.

Assignments 2 allows the setting of the values or properties of the child records. These value assignments can retrieve values from other related records or can be “Hard Coded” into the assignment string.

In this example the fields on the Site Diary Work Activity are set to :-

A. Ipm_date=primary.ipm_date This means the date comes from the Site Diary header record that is the workflow parent.

B. Ipm_description=parent1child.ipm_name This means the description field on the Workactivity record will be set to the child specified in Relationship 1 which is the job task Description field.

C. Ipm_productionunitsuomid=parent1child.ipm_productionunitsid this means the Work Activity Production Units field will be set to the production UOM field off the job task record.

Workflow 2 allows the specification of a workflow to run on the child records if they were created by the process and did not fail the duplicates test.

Workflow 3 allows the specification of a workflow to run on the child records if they were not created by the process due to the duplicates test.

“Commitment Line Budget Check” Workflow Action

This workflow action allows a commitment line to evaluate the total value of commitments against a particular job task against the total budget for the Job task. It returns a number of values including to total budget, total commitment value and the amount of budget overrun if there is an overrun. This overrun amount is totaled to the Purchase Order/Subcontract Order header so that this information can be used in approval emails.

“Get Standard Spec Section” Workflow Action

The “Get Standard Spec Section” is designed to relink a Job Spec Section to a Standard Spec Section. This can be used if additional properties (Fields) are added to the Standard Spec Section that are required to be utilized on a Job Spec Section for reporting.

“Get Standard Task” Workflow Action

The “Get Standard Task” is designed to relink a Job Task to a Standard task. This can be used if additional properties (Fields) are added to the Standard Spec Section that are required to be utilized on a Job Spec Section for reporting.

”Job Auto Bill ” Workflow Action

The “Job Auto Bill” workflow action is designed to create progress bills for contract lines setup as Autobill contract lines. The underlying concept behind this feature is that although most of our clients are involved in large projects, some of them provide ongoing maintenance services once the project is complete. These “maintenance jobs” usually have a contract associated with them that provides for regular billings which need to be

In order to deal with this requirement we have created a new Auto-Bill workflow action. This action is only applicable to the Job Record. We have added 2 new fields to the Contract Item/Schedule Item record.

The Auto-Bill Type field determines how the Auto Bill workflow work-flow action interacts with the item. If the Auto Bill Type is set to “No” then the work-flow action will ignore the line. If the Auto Bill Type is set to Periodic then the workflow will always bill the item. If the Auto Bill Type is set to once then the work-flow will bill the item only the first time the work-flow is run against the item and from then on will be ignored.

Any additional logic as to which jobs should be billed and how to print the invoices for these jobs should be managed in the custom workflow used to run the Auto Bill action and through the creation of custom views.