The August patch release in EPM Cloud hit test pods on Friday, August 7 and will be coming to Production pods this coming Friday, August 21. For Enterprise Data Management Cloud (EDMCS), there were 20+ new feature updates that were released; which means – this is going to be a series of posts. 🙂
First up – the Notification Policies!
From a workflow perspective, EDM uses a combination of security, subscriptions, and approval policies to derive the governance processes for making enterprise data updates (dimensions, segments, whatever you want to call them).
Prior to 20.08, we’d break workflows down into 2 key user groups:
Submitters/Collaborators – Data Stewards that are making and modeling changes to enterprise master data; adding new members, adding insights into changes, etc.
Approvers – Data Owners that are ensuring that the meaning, codes, and intended usage of the data is applicable for the target system(s) for which it is applicable.
However, what about people in the organization that are not responsible for these updates; but they need to know about them? Maybe they need to update a report or SmartView retrieve, or update a periphery system that is not part of the EDM ecosystem? Or just to know that the change was made as an FYI?
Enter the Notification group.
Notification Policies Setup
Similar to Approval Policies, you can set up Notification Policies on different layers on the Data Chain. The Notification Policy allows for an email to be sent to a security group(s) or specified user(s) whenever changes are made. You can apply logic and limits to the notifications, which we will talk about more in a bit.
In EDM, you can create a Notification Policy on:
- Hierarchy Sets
- Node Types
On the data chain object, if you Inspect the object, you can manage policies on the Policies tab. In my example, I have a Universal adapter that has a list of Engagements; and I’d like to know when any changes are made to the Engagement list.
When you press Create, the system walks you through a small wizard to get started. First, select if you like to add an additional Approval Policy (one inactive one defaults on any data chain object – you can choose to enable it or not) or if you’d like to create a Notify Policy.
Name the policy and press Create.
This then takes you to the new policy for refinement. You can press Edit in the top right if you need to rename your policy. The General tab has the name and description, but also shows it is a Notify Policy.
Below that, the Workflow Stage shows “Closed” – this means that the Notification occurs whenever a Request is actually committed or Closed in EDM. There will be notifications only when data is edited or changed – not when it moves into any other state, such as Approve, Reject or gets deleted. Only committed changes, that have been designated as Closed will be a part of this Notification. I am hopeful that due to this being exposed in the interface, that other types of notifications can be enabled for other workflow stages in the future.
Also notice that the is robust tracking of who created and last edited the Policy.
Moving to the Definition tab, this shows who should get Notified on committed changes to the Data Chain object (remember, my example is on the Dimension “Engagements”).
By pressing the arrow on the right next to “Add a policy group” you can add both security groups (ex: WORLD) or individual users (Kate_Test) to the policy. You can enable or disable the policy using the check box on the left.
On the final tab, Filters, you can add conditions or action filters to ensure that notifications are sent for only pertinent items to the audience. You may enable several Notification Policies, for example, for different purposes.
On the left, the Included Actions allows either “ALL” actions to be included in the Notification, or you can specify the Actions needed – for example, maybe a group only wants to be Notified for newly Added members and do not care if there were Moves or Reorders.
On the right of the Filters tab is the Node Conditions. Similar to how they are used in Subscriptions (see my post on those here) you can add conditions to include specific nodes for updates. For example, if users only want to see notifications for nodes with a specific prefix, or maybe just base level members, you can use expressions to limit it.
In order to use the Node Conditions, in the expression you must render a boolean of “True” for nodes you want to include, and “False” for those you do not.
After saving your changes, your Notification Policy is ready.
If I go back to the Policies tab on my “Engagements” dimension, I see the Policy and the Policy Type, Workflow Stage, Enabled status, and Groups/Users included in the policy.
One thing I did notice, if you go to the Permissions tab on the Dimension (or whichever data chain object to which you added the Notification Policy), you can see that the user and security group are now set to “Owners” of the dimension – which did not exist prior to the Notification Policy being set up.
We have done some testing on this – although it says “Owner” – it is only within the context of the Notification Policy and not true “Owner” permissions. From testing, users on the Notify are only read only and cannot make edits with this designation. If they are supposed to edit, you can add another Permission for the same group or user.
Finally! Testing the Notification policy; I added an Engagement to my Engagement dimension – which then triggered my Notification policy. Currently, there is no way to edit or format the EDMCS emails that are sent for any purpose (Notifications, Approvals needed, Invitations to Collaborate, Completed Requests, etc.).
Clearly, the missing piece from the email is clearly the detail of what was changed. Users will need to click the hyperlink at the top of the email to navigate into EDMCS to see the details of the request.
Clicking the link (after logging in) will take the user directly to the request. No other clicking required:
Thanks for reading! I think Conditional Approval Policies may be next – followed by the new Reports card/button. Let me know if you have any questions or requests for information.