Since I am using “event” entity to actually work with the event registrations through the extra fields (see Part 3 of these series of posts), I need some server-side logic to process those fields.
In this post, I’ll describe how it’s been set up using classic Dynamics workflows, but it might be interesting to convert all those workflows into Flows, so maybe that’s what I do in one of the following posts. For now, though, let’s have a look at the processes below:
The first one on this list is a custom action that returns portal url as an output parameter. This way I only need to update the url once when/if the portal moves, and I can use that custom action in the email notification workflows without having to update those workflows in such cases:
The second process is an on-demand workflow that will de-activate event registration – nothing extraordinary there:
The third one is an on-demand workflow that will take an event registration and pull it from the waiting list, so it will:
1) Update a couple of properties on the event registration
2) Send an email to the contact
3) Reduce the number of available registration slots on the event
4) Wait for a couple of days
5) And, if the registration has not been confirmed by the contact after those two days, it will deactivate the registration
You will see that it’s using Get Record Id custom workflow activity to get the id of the records. And it’s using another child workflow to recalculate available registration slots. In both cases, it’ll be using custom workflow activities from the TCS Tools solution:
http://www.itaintboring.com/tcs-tools/solution-summary/
In particular, that “Recalculate Registrants” step will use an attribute setter custom workflow activity to get the number of active registrations linked to the event and to store that number in the “Number of Registrants” field on the event entity:
Once it’s there, remaining timeslots field on the event entity will be automatically recalculated:
Then, there is another workflow that will create or update event registration record when needed (again, this one is registered on the event entity since that’s how the data will be coming in from the portal):
Finally, whenever an event registration is deactivated/created, a workflow will start on the event registration:
This workflow will start a couple of child workflows. We’ve seen the first one already – it’ll recalculate available slots on the event.
The second one will check if there are free slots, and, if yes, it will try pulling an event registration from the waiting list, and, if there is one, it will start “Pull From Waiting List” workflow on that record – we’ve seen that workflow above, too. This is done with the help of TCS tools, again, so here is how it looks like:
And, btw, if you are wondering how the current version of the event registration web site looks like, feel free to have a look here:
https://treecatsoftware.microsoftcrmportals.com/
As of Dec 6, there is a test event there that you can try subscribing to. I might, as well, use it to set up a real event (training maybe?), but that’s still to come..