I ran into an interesting requirement on a recent MDS engagement. The customer wanted to give a large number of users read-only access to the MDS data. While they didn’t want most of the users to be able to update the Master Data, they realized that the users would frequently find issues with the Master Data. They wanted the users to be able to suggest changes and corrections to the Master Data so the data could be fixed in the source system.
We decided to use permissions to make the attributes of the key master entities read-only while creating an updatable text attribute that users could use to report issues. This worked well but we needed to inform the source system owners when an issue was reported so they could fix it quickly. Our first attempt was to just create a business rule that fired when the change-request attribute was updated and used the normal notification mechanism to send an email to the data steward when a change-request field was populated. This worked OK but the data steward was forced to click on the link to go to the MDS database to find out what the change-request text said. In this customer’s environment data stewards didn’t necessarily have access to MDS so this was inconvenient. To simplify the data steward’s life, we wrote a customer workflow class that was called when the change-request attribute was updated. The custom workflow made a web service call into MDS to retrieve the contents of the change-request attribute, composed an email with the change-request and other pertinent information and made a DBMail call to send the email to the data steward.