Written By:

Janetta McCreery
Technical Writer Nakisa Hanelly
Nakisa

If you read my previous post, you learned that Nakisa Hanelly restricts what data your users can see, based on the role they hold in your organization. In addition to defining security by role, you can determine what secure data your employees see by selecting a security model based on nearly any other variable you maintain in your database. I know this sounds confusing, I certainly had difficulty describing it for our documentation, but it’s a cool and powerful feature, so I want to take the time to explain it properly.

Hanelly’s Original Security Model

When we first introduced Nakisa Hanelly in 2015, we only had one security model, which we called Area of Responsibility or AOR. This security model was designed so that that the secure data users could see was limited to themselves and the people they managed. You may hear a Nakisa representative refer to this as “self-and-below” also. Users could log in and see secure data (things like salary or employment history) for themselves, the people they manage, and the people their employees manage.

In this image, Roberto Pilson can see a view that contains salary data (which is a secured field), but he can only see his and his employees’ salary information. He cannot see Charlie Peck’s salary data or that of his employees.

The AOR/”Self-and-Below” Security ModelLocation-Based/Matrix Security

After a few versions, we introduced a new security model that allowed managerial users to see secure data based on the location of the user. So instead of seeing secure data for the people who report to you, you would see secure data for everyone in your location. Typically, this security model was configured to show data from the same city but could also have been configured to be in the same country or region.

In the following image, Helle Carlson is a manager in Dubai. He can see the secure data in his department, as well as other departments in Dubai, including Roberto Pilson’s and Connie Brammer’s. However, he cannot see the secure data from departments in other locations, such as Chicago, New York, Malaysia, and Singapore.

The Location-based data option was our second security-model offering for Nakisa HanellyLatest Matrix Security Options

After we introduced the location-based security model, we realized that if we could secure the data by one type of data element, why wouldn’t the next logical step be securing the data by any data element that you store in your database? What if our clients want everyone who has the same job title to be able to see each other’s secure data? Or what if you have HR Business Partners who need access to data in their time zone? Perhaps your new CTO is a bit “new age” and wants to secure data based on zodiac sign, because Capricorns don’t have the same management styles as Libras! With our latest release, you can now establish access to secure data based on any kind of data element you have in your system. As an added bonus, you configure those kinds of security models yourself in the AdminConsole—you won’t even need to get consulting time from Nakisa to configure it for you.

Matrix Security Limitations and Future Security Plans

Now, as cool as the new security options are, there are a few limitations in the Matrix security models that are not in the original Self-and-Below models. Because of the way Nakisa Hanelly aggregates and reports data, there are some features that are available in the AOR security model that are not applicable (or not programmatically possible) in the Matrix security environment. The most noticeable limitation is that Matrix security models do not allow for the creation of Work Areas. If you’re not familiar with Work Areas, they’re what allow the directors overseeing reorganizations to delegate portions of an org chart to managers closer to the departments being reorganized.

The business logic for work areas requires the secure data to aggregate upwards from each department, so a security model based on city or Zodiac sign won’t display or add up correctly. Because of this, we wanted to give a way for our clients to provide access to secure data based on whatever criteria they want, while also allowing them to use the full functionality of our reorganization/M&A and all of the analytics and planning power that includes.

For our next releases, we’re planning to split up the security between what you see in your live org chart and what you can do with your scenarios. We’re going to allow you to have your Zodiac-based security in the main org chart, while simultaneously giving you the option in your scenarios to have the self-and-below security configuration that allows you to delegate work areas and track each department’s progress towards your targets and objectives. With these new additions to the application, we hope to continue providing more and more opportunities for you and your employees to use the application to understand and continually improve your organization.