IPM Global Custom Workflow Actions.

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

Add Business Days

Add Business Days adds business days based on the IPM Calendar and any Job Calendars that are setup for a particular job.

“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 conjuction 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.

“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 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.

“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.Fetch Scalar, Fetch Scalar Decimal, FetchScalarMoney

Fetch Scalar is a workflow action that allows on-demand totals of values from record sets defined by a fetch statement. As an example, on the IPM Contact Record we show the total Subcontractor Evaluation Score, the number of subcontracts the subcontractor has been scored on and the total number of Defects the subcontractor has been associated with. To get the totals we get the FetchScalar workflow action. The action can be used to sum or count any values from any Dynamics 365 record set.

There are 4 inputs to a FetchScalar and 3 outputs.

We would suggest that Fetch Scalar be used in preference to the other 2 actions.

Copy Linked Documents to Notes

This workflow action will copy documents stored in IPM's linked Document facility to the current document notes area. This is essentially used to move these files onto Dynamics notes so that they are available in the field.

Copy Notes to Linked Documents

This WF action copies notes to IPM's linked documents facility.

Create Email

As the name suggests, this is designed to automate the creation of an email, however the email it creates is the one that would be created if a user clicked the orange "Create Email" button.

Create Transmittals for Job Drawings

This workflow action, designed to be triggered on the Job Record, reads the log of drawing revisions and creates a transmittal for each logged recipient. For this action to work a number of actions must have previously occurred:-

Drawings have been attached to outbound communications such as transmittals, subcontracts and RFI's.
The distribution lists on these drawings must have been updated with the recipients if the documents from point 1. This occurs automatically if workflows are in place. A full set of workflows is available from IPM.
The Drawings must have had revisions loaded in either using the IPM Document uploader or by using the "New Revision " button on the Drawing Register.
Once revisions have been loaded, this workflow action should be triggered on the job. If required, transmittals can be sent automatically by adding the "Create Email" action to the workflow.

Get Account ERP System Record

This is used to determine whether an Account Record has a valid ERP system link. This is designed to be used in the process of approving purchase orders or purchase invoices to provide a hold point if the document refers to an account that has not been linked to the accounting application.

Get Attribute Value

This allows the retrieval and/or conversion of attributes. If for example a GUID for a record is required but only the lookup value is available then this action will provide the GUID. Alternatively if a date is required for a fetch statement, it is not possible to pass in a date directly from a record using the form assistant, however this action will convert the date to text.

Get Commitment Balance

This retrieves the unclaimed value of a purchase order or subcontract.

Get Contract Amounts

This retrieves the Total Contract Value for a project

Get Document Template

This retrieves into context a word template based on a text value and is used in conjunction with the Run Merge action.

Get ERP Costs

This retrieves the total value of costs as defined by the query in the ERP settings. It is essentially to provide information about costs for a project from an external source.

Get Estimate Usage

This calculates the amount of a budget line that has been consumed by Purchase Orders, Subcontracts and Material Shipment.

Get Gross Claimed Amount

This action retrieves the latest gross claimed amount for a subcontract line item.

Get IPM Contact

This action either retrieves or creates an IPM Contact from an Account, Contact or User.

Get Item Cost

This retrieves the cost of an item based on the costing method.

Get Job Contact by Role

This action retrieves the first contact it finds for a job that has been assigned a particular role.

Get Job Task

This retrieves / creates a Job Task based on a Standard Task

Get Total Budget

This action returns the Original Budget, Approved Changes a the Revised Budget for either a Job Task or a Job as specified.

Get Total Commitments

This action retrieves the Total Vale of Original Commitments, Approved Changes and the Revised Commitment value for a Job or Job Task with an optional cutoff date.

Get Total Commitments Invoiced

This action retrieves the Total Commitments Invoiced for a Job or Job Task with an optional cutoff date.

Get Total Cost

This action retrieves the Total Costs for a Job or Job Task with an optional cutoff date.

Get Workflow Context

This returns the current user. It is specifically designed for Dialogs and rel time workflows however appears to work for background processes as well.

Portal.GenerateTemporaryPassword

Generates a temporary password for a Portal User record

Portal.GetPortalInfo

Returns the Portal URL

Process Linked Documents

Provides functionality to move / copy documents stored in IPM's linked document facility between records. Note that the reference field required to identify the target needs to be the field name manually typed into the attribute value, not picked from the Form Assistant.

“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.

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.

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 :-

Ipm_date=primary.ipm_date This means the date comes from the Site Diary header record that is the workflow parent.
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.
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.

Additional Technical Notes

Notes to using “ProcessChildRecords” Custom Workflow Activity

Primary entity – a record upon which our workflow is being executed

PARAMETERS FROM THE ABOVE SCREENSHOT:

Parent 1:

Relationship 1:

Entity 1: ipm_purchaseorderitem

Workflow 1: WF_POItems1

Filter 1: ((ipm_purchaseorderid.ipm_jobid==primary.ipm_jobid)&&(ipm_amount_base>entity1.ipm_approvedinvoicesamount))

Parent 2:

Relationship 2:

Entity 2: ipm_sd_material

Workflow 2:WF_SDMaterials2

Workflow 3:WF_SDMaterials3

DESCRIPTION OF PARAMETERS:

Parent 1: leave it empty (path to parent of source child records from primary entity, for example, ipm_jobid – it will mean parent is our primary entity Job, we can use dots: ipm_jobid.ipm_billtocustomerid.ipm_crm_accountid – then our parent entity will be a CRM account related to Job “Bill To Customer”)

Relationship 1: leave it empty (name of the relationship between parent and source child records)

Entity 1: ipm_purchaseorderitem - you can refer to this entity in “Assignments 2” parameter by using prefix “parent1child.” OR “entity1.” (you need to specify only Parent 1/Relationship 1 pair of parameters OR just Entity 1)

Workflow 1: specify a workflow to be executed for parent1child/entity1 records (if required)

Filter 1: ((ipm_purchaseorderid.ipm_jobid==primary.ipm_jobid)&&(ipm_amount_base>entity1.ipm_approvedinvoicesamount))

(see below for acceptable syntax of Filter expressions)

Parent 2: leave it empty (if it’s empty it means Parent 2 = primary entity)

Relationship 2: you can specify ipm_ipm_sitediary_ipm_sd_material relationship here OR leave it empty and specify next new parameter

Entity 2: ipm_sd_material - you cannot refer to this entity in “Assignments 2”

(you need to specify only Parent 2/Relationship 2 pair of parameters OR just Entity 2)

(if you specify Relationship 2 and leave Parent 2 empty – it means that primary entity will be used)

Assignments 2: specify how to set values for target child records, you can use prefixes: primary (current entity - here it is a Site Diary entity), parent1, parent2, parent1child OR entity1 (the are both referring the same record)

In this example if we use Entity 2 instead of Relationship 2 we need to assign a parent attribute ipm_sitediaryid=primary.ipm_sitediaryid, if we use Relationship 2 – we don’t need to add this assignment

You can use any number of dots to reach required value in the right part: ipm_purchasedfromid=entity1.ipm_purchaseorderid.ipm_vendorid

Please note, no calculations can be used in the right part, for example: 1+2, entity1.ipm_type+1, entity1.ipm_quantity*entity1.ipm_rate

Workflow 2: specify a workflow to be executed on newly created parent2child/entity2 records (if required)

Workflow 3: specify a workflow to be executed on already existing parent2child/entity2 records (if required)

SYNTAX OF FILTER EXPRESSION:

Correct syntax:

1- double round brackets can be omitted if there is only 1 condition

(1) - one set of round brackets can be omitted if there is only 1 condition

((1))

((1)&&(2))

((1)&&(2)&&(3))

((1)||(2))

((1)||(2)||(3))

((1)&&(2))&&((3)||(4))&&((5)||(6))

((1))&&((3)||(4))&&((5)||(6))

((1)||(2))||((3)&&(4))||((5)&&(6))

((1))||((3)&&(4))||((5)&&(6))

Numbers 1,2,3,…,6 above mean different conditions (a condition example:ipm_type == 5):

condition1, condition2, …, condition6

Any number of conditions (1 or more) can be used in a filter expression

Note that the same operator is always used between outer sets of round brackets (…)&&(…)&&(…)

And inside each set of outer brackets (…) there can be 1 or more conditions divided by the same operator: for example (1)||(2)||(3) or it may be (1)&&(2)&&(3) or just (1)

You cannot mix different operators between outer sets of brackets: (…)&&(…)||(…) – incorrect!!!

You cannot mix different operators inside each outer set of brackets: (1)&&(2)||(3) – incorrect!!!

But you can use one operator inside one set of outer brackets and another operator for another set of outer brackets:

for example:

((1)&&(2)&&(3))&&((4)||(5)||(6))&&((7)&&(8))

((1)&&(2)&&(3))||((4)||(5)||(6))||((7)&&(8))

Incorrect syntax:

((1)&&(2)||(3))- using && and || at the same time – should be: ((1)&&((2)||(3))) or((1)&&(2))||((3)) or ((1)||(3))&&((2)||(3)),etc

((1)||(2)&&(3)) - using && and || at the same time – should be: similar to above

1&&2- each condition is not in round brackets – should be: ((1)&&(2)) or ((1))&&((2))

1||2- each condition is not in round brackets – should be: ((1)||(2)) or ((1))||((2))

Logical operators between conditions:

1) You can use any of the following to make logical “OR”:

2) You can use any of the following to make logical “AND”:

Conditions:

Each condition consists of leftpart operator rightpart

Example: ipm_type==5

where ipm_type – attribute of parent1child/entity1 (don’t use any prefixes here),

you can use dots to reach your attribute in the left part: ipm_purchaseorderid.ipm_jobid

== means equal (you can use other condition operators – see below),

5 – the right part: can be just a value 5, 12, “aaa”, aaa, “12/05/2013”, 12/05/2013, GUID, “GUID”, “{GUID}”, {GUID}, NULL

Or you can use dots to reach required value in the right part (“primary.”, “parent1.”, “parent1child.” or “entity1.” prefixes can be used here), for example:

primary.ipm_jobid

primary.ipm_jobid.ipm_number

primary.ipm_jobid.ipm_billtocustomerid.ipm_type

primary.ipm_jobid.ipm_billtocustomerid.ipm_crm_accountid.number

Please note if you need to use “parent1child.” or “entity1.” prefixes in the right part of a condition, then:

only operators that mean “=”, “<>”, “<=”, “<”, “>”, “>=” are allowed
the condition must belong to the filter expression of the following types (assume that our condition has number 1):

((1)&&(2))&&((3)&&(4))

((1)&&(2))&&((3)||(4))

So that, underlined operators must be Logical ANDs (for outer sets of brackets and inside set where our condition is located, other sets can have Logical OR)

Please note that string/date/GUID values can be used with or without double quotes and curly brackets

Right part may be omitted in some cases: where “null” or “notnull” or “equaluserid” operators are used

Please note, no calculations can be used in the right part, for example: 1+2, primary.ipm_type+1, parent1.ipm_quantity*parent1.ipm_rate

Condition operators:

You can use any of the following – they all mean “=”:

==
=
equal
eq
is

You can use any of the following – they all mean “<>”:

!=
<>
notequal
ne
isnot

You can use any of the following – they all mean “<=”:

<=
lessequal
le

You can use any of the following – they all mean “<”:

<
lessthan
lt

You can use any of the following – they all mean “>=”:

>=
greaterequal
ge

You can use any of the following – they all mean “>”:

>
greaterthan
gt

You can use any of the following after attribute name – they all mean “is null”:

ipm_type == null
ipm_type = null
ipm_type equal null
ipm_type eq null
ipm_type is null
ipm_type null

You can use any of the following after attribute name– they all mean “is not null”:

ipm_type != null
ipm_type <> null
ipm_type notequal null
ipm_type neq null
ipm_type isnot null
ipm_type notnull

Date operators:

on
noton
onorafter
onorbefore

String operators:

contains
doesnotcontain
beginswith
doesnotbeginwith
endswith
doesnotendwith
like
notlike

List operators:

in
notin
between
notbetween

Operators that don’t require right value:

null
notnull
equaluserid

Run Merge

This action performs a Word Merge using the template identified in "Get Document Template". It allows the target location for the merged document.

Utilities.xxxxxxxxx

This is a collection of standard utilities provided to perform useful things in different situations.

IPM Custom Workflow Activities (2)

This is a set of actions specifically designed to work with date manipulations and is used extensively in our Forecasting workflows.

AddBusinessDays : This is a conventional function to add business days to a date and does not use the IPM Calendar function. The IPMAddBusinessDays

AddDays : Simply adds days to a date