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.
