Hello and welcome to my first blog post!
For those that would like a video please see below…
For those like me who just want the answer on how its built, in text, so you can skim read it really quickly, figure it out and reproduce keep reading.
A few weeks ago, as part of my talk at Dynamics 365 Saturday Sydney, I presented a demo I built that demonstrated what I consider to be some advanced CRM portal features. As a kick start for my blog I’m going to take that demo and use it for the first few articles.
The big feature I wanted to communicate as part of my talk was the portals ability to facilitate an approval process. By using the ADX Workflow helpers and having multiple web forms with different modes and record source types I can enable one customer to trigger a process that allows another customer to interact with the same record. This can get very tricky from a licensing perspective but I still think it is a valuable tool. Early disclaimer – if you ask me any questions about licensing (**snores loudly**) I will just refer you to Microsoft. This ‘approval’ process could be anything from an expense claim or a leave request through to one customer asking permission of another to purchase something. It doesn’t even need to be an ‘approval’ process. The functionality facilitates one customer, new or existing in your system, to create a record and another customer to interact with that record.
The first step is to set up a CRM portal form that creates a record. On that form you need to place a piece of metadata that changes a value that in turn triggers a workflow.
Below I’ve got a metadata record on the last step of my webform that changes the status code / status reason field. I’ve configured the record to ‘Set Value on Save’.
The second step is to create a workflow that grabs the records GUID, triggered by a field change. If you are using a one step web form or an entity form, it’s entirely possible to trigger this workflow off creation. Below is my workflow. In the third action I update a custom field on the record I use to house both the hard coded link to the specific portal page and the dynamic value of the adx workflow helper that retrieves the GUID. In the fourth action I send an email to a contact with the link I created in the third action. You could create the link in the email however I’ve found having it in a field is useful for troubleshooting and when the process breaks i.e. someone lost an email.
Third step is to create another portal form that either edits or just reads a record on the same entity as your first form. The source type needs to be set to query string. The primary key query string parameter name field needs to be set to whatever you put before the GUID, so ‘id’ (the default), and the primary key attribute logical name needs to be set to the field you are pulling this value from. The adx workflow helper is pulling the GUID of the record so set it to record id field! Clear as mud? Below is my web form step.
I’ve used a customer, or rather a contact throughout this demo as an example of what is possible. The portal authentication and security works on contacts so it makes sense to use that entity as a recipient of the ‘go to portal now email’, but it doesn’t necessarily have to be. For example you could use leads, accounts etc. I like using contact however as in a real life scenario I would put my third step on a webform that requires authentication and then captures who was signed in. I know I can configure security around the record through entity permissions but its still nice to know that when I sent it to Leon, Leon approved/rejected/interacted with the form.
If you’ve made it this far, thanks for reading! Next time I will go through the other half of my talk from Dynamics 365 Saturday Sydney and demonstrate how to get you customers to trigger on demand workflows in the portal and how to show multiple types of records on one page.
If you have any feedback or questions please don’t hesitate to reach out via comments below or LinkedIn.