MDM Security Permissions To Safeguard Data
A good MDM Security Permissions plan gives end users a seamless system for inputting, protecting, and utilizing their data to the fullest.Click to tweet
Teams that do their own thing are generally successful until management wants a picture of how everyone is doing. It’s typical for several teams to make updates. But you don’t want Team A mistakenly making changes to Team B’s data and vice versa.
Let’s say you have a situation where the datasets require input from many teams. Then you have common data elements between teams, like Regions, between Sales, Manufacturing, and Operations, or Apps between Developers, Partners, and Customers.
Even when, at face value, these common data elements seem intuitive, tagging them may be hard. For example, each team could use a different tracking system, or perhaps there are legacy products and services, or multiple acquisitions over time. Well planned MDM Security Permissions will protect each category of data.
Master Data Services (MDS) in SQL Server allows three types of security:
- Functional area access, or permissions for users to access the following areas of the MDM user interface: Explorer, Version Management, Integration Management, System Administration, User and Group Permissions
- Model object permissions, which “locks down” what forms (entities) or fields (attributes) users can read or modify
- Hierarchy member permissions determine what portion of a hierarchy various users can read, update or delete. In other words, set users or groups (i.e. teams) to modify their portion of the data. Examples include allowing different regional planners to update store information for just their region; or requiring different divisions to update their quarterly goals
When you look at your overall MDM solution, you should think about all three of these areas. If only IT is allowed to change the MDM model, then other groups should not have access to System Administration. If Data Stewards are not allowed to modify data synchronized from other source systems, mark those tables and/or attributes as read-only. If certain groups or users should only see their portion of the data, use hierarchy member permission.
Do your research first. Take a look at my article on MDM User Interface Design Best Practices and this excellent MDM infographic from Profisee. By thinking about these security loopholes, you’ll ensure that each team’s data is protected. A good MDM Security Permissions plan gives end users a seamless system for inputting, protecting, and utilizing their data to the fullest.
Angel Abundez is VP, Solutions Architecture at DesignMind.