Restrict Access to Publish Journeys in Dynamics 365 Marketing
The ‘Publish’ button on a journey in Dynamics 365 Marketing is pretty powerful. It’s what makes emails send out and automation magic happen. It’s the final gate of validation where the system checks everything is technically correct - emails are marked ‘ready to send’ and aligned to the audience chosen, compliance is set up, branch conditions are complete, triggers and segments are ready to use etc. But it doesn’t check things like:
Is the segment targeting the right people?
Are the sequence timings/branches set up according to the campaign plans?
Are the correct email(s) being used?
Do the emails look ‘right’ and approved by all relevant parties?
Is the start date correct?
Did you use the right exclusion segments?
The list goes on! It is all very subjective and it changes per campaign, no technical solution can fix this. This is why we need marketers and the teams they work with. But what we can do is prevent people from being able to intentionally or unintentionally publish a journey which is not ready for the world. This gives the user reassurance that no matter how hard they try they cannot incorrectly publish a journey so they are more confident in learning to use Dynamics 365 Marketing on a daily basis. It gives all the other vested parties (technical support teams, marketing & business relationship managers, leadership personnel etc.) reassurance that things are less likely to go wrong. Hopefully this can help more customers success with Dynamics 365 Marketing!
The error message shows in the journey designer where all the other messages are shown for a nice consistent UI experience - yay!
Add a column security enabled column to the Journey table
Since we can now edit the journey form/table we will go and add a new column which will be used to make the journey as reviewed and allow users to publish it. Ensure the column has column security enabled. You can use any type of column/set up here you just need to be able to define a condition against it that indicates publish is allowed/not allowed. You could also add extra columns to capture who approved it and a timestamp too.
Create a new field on the journey table. In my example I created a Yes/No field called ‘Reviewed’. Ensure the default is a value that will not allow publish and that column security is enabled.
Set up Column Security Profiles
You might add new profiles or use existing but there are two personas to cater for here.
Journey builder - can create the journey and associated items, and finalise it ready for review. They cannot publish the journey until it has been reviewed - Read & Create: Allowed. Update: Not Allowed.
Journey publisher - can review and approve journeys to allow the Journey builder publishing powers - Read, Update & Create: Allowed.
Column security profiles for Journey builder and reviewers. You will need to assign users/teams to these profiles accordingly too.
Edit the journey form
Add your new column onto the Journey form in the ‘Settings’ tab. Save and publish.
Create a classic workflow process
Yeah I said it a classic workflow, I’m not even sorry, these little things are terribly useful despite their ‘classicness’.
Ensure you create the workflow to run real-time so the ‘Run workflow in the background’ box is unticked
This is not a workflow that we want to allow to run in the background! Recommendation rejected.
Configure the workflow
Ensure you set up the options correctly as seen below.
Scope: Organization
Starts when: Before a Record status changes
Execute as: The owner of the workflow
Two simple steps in the flow:
Add a condition to check if the Status reason is Draft and Reviewed does not equal Yes
If the condition above is true - Stop Workflow with status of Cancel. Set Properties and add a reason such as ‘Review must be completed before publishing the journey’.
Save -> Activate -> Done
NOTE: Make sure the owner of the workflow has been added to one of the field security profiles as they need READ access to the field to check the value, even if they are system admin you must add them to the Field (column) security profile for this to work.
The end
That’s it - done. And be assured that even if your sneaky Journey builder tried to update the reviewed flag to yes, they will be stopped! There are so many more layers of review/approval you could add to this but knowing its possible to safeguard new users on the system is a massive win!
