CONTACT
Angel Abundez Angel Abundez

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
Your data is dependent on those who have access to it, so you need to choose which users have access to data based on task relevancy. That’s where MDM Security Permissions come in. In a nutshell, you want to keep your read-only data and modifiable data just that—readable and writable only by authorized users.

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.MDM Security Permissions To Safeguard Data from DesignMind

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.