Principles
Open Defaults
We believe that your architecture is most useful when it can be shared broadly. Context is king, both for humans and AI, and an authorization system which promotes information hiding creates complexity and is predicated on near-perfect alignment between your access configuration and your users' intent.
Therefore, our defaults strive to achieve a visible architecture over an architecture dictated by "least privilege". While this runs counter to how some organizations operate, we strongly believe in it (having seen the cost, complexity & overhead that many fine-grained authorization systems create). Some have dubbed this approach "radical transparency".
Personalization over configuration
One cost of open defaults is "context bloat": when you share everything, you also share unrelated things. This produces visual clutter, it creates data quality issues through incorrect modeling, and it increases navigational friction.
One could try and configure your way out of this with sprawling read access rules (hide these fields, hide this data, etc), and attempts to do so drive a lot of product feedback. However, we don't believe this is a fruitful direction: it creates a configuration burden for administrators and -- more problematically -- hides data for reasons of relevance instead of data privacy. Of all the reasons to hide context from your organization, simplifying the user experience is the worst!
We believe the personalization is the way forwards -- the system should support an open architecture by presenting relevant information to your end-users with the least amount of configuration required. This is even more important in an AI-first world, and it's the direction which drives our product roadmap.
Best Practices
As a baseline, only configure what you need. Sometimes we see customers start by configuring a 1-to-1 reality with their org chart (e.g. one group per team) instead of starting from the minimum level of configuration needed to accomplish their access outcomes within Ardoq. We recommend to start small and expand.
General Recommendations
The following guidelines assume that you've setup SSO. If you haven't done so, we highly recommend using SSO for both security and scalability reasons.
1. Define the default role for your organization
1. Define the default role for your organization
Ardoq has 4 roles. We generally recommend that your default role should be either Reader or Contributor in order to reserve write capabilities for more privileged users who will have the Writer role. When to choose one or the other? It primarily depends on whether you are taking a "Discover-first" approach:
Choose the Reader role if you want your users to have access to core Ardoq by default, allowing them to view the full product but still with limited write capabilities.
Choose the Contributor role if you want your users to primarily work in Discover with a simplified experience.
Most of the time, we recommend starting with Contributor.
In order to set the default role for your organization, you currently need to go through Customer Support.
2. Define how to treat the data within each of your workspaces, and what your high-level user groups should be
2. Define how to treat the data within each of your workspaces, and what your high-level user groups should be
Determine which data must be hidden
Your first decision is about the data privacy of each of your workspaces. Following the principle of open defaults, your first question should be about which workspaces should be hidden from most of your organization:
Set the "Entire organization" setting based on this decision, for each of your workspaces.
Note: In Organization Settings you can control the default permissions for new workspaces, to avoid having to configure this each time going forwards. Following "Open Defaults", we suggest using Can View for this setting.
Determine who should be allowed to manage the data in each workspace
Following the step above, most of your users should have read access to most of your repository. The question is then how to "punch a hole" for edit rights in each workspace for the right people to manage the data. We recommend going through your workspaces and asking "who in my organization should be allowed to manage this data?"
This exercise is meant to surface how few groups you will be able to get away with.
In our experience, mapping your organization 1-to-1 with your user groups creates premature configuration overhead. It is very easy to create more groups and assign those groups to workspaces in the future!
In most cases, it's likely that you will only have a handful of groups you really need to have in Ardoq.
3. Create & populate your groups
3. Create & populate your groups
With your high-level user groups defined, go ahead and create them in Ardoq. While we have no way of importing your user groups directly from your IDP, we allow you to manage membership in your user groups automatically with SSO Attribute Mapping.
So you have two options:
Manually populate your groups within Ardoq: This approach is less scalable, but may be the only option if your SSO doesn't have the right attributes to match your desired configuration.
Create SSO mapping rules: This is much better at handling the lifecycle of your people, and will automatically update as your people change roles. In order to do so, you will need to ensure that your desired group(s) have something which indicates their common membership. For example, a department field, a team field, etc. Ideally this already piggy-backs on team structures you already have, and this is a painless change.
Common Antipatterns
Creating a group corresponding to each role
We occasionally see customers create groups corresponding to each role. This may feel natural, but rarely serves a useful purpose and often drives further confusion between Groups and Roles. Roles exist to create a floor/ceiling for a user's access, but they are not meant for organizing or grouping users, and they cannot be used for assigning access to individual resources.
We suggest that you should be creating groups according to the responsibility of your users, and based on your desired access configuration.
FAQ
How do I make sure an Application owner can only update his/her data? Workspace permissions are too coarse, and I'm worried about data quality.
This is something we hear often. Firstly, we understand the concern, though in our experience the risk of accidental / inadvertent changes to applications you don't own tends to be rather low. So it's worth questioning whether this is about navigation (bring my users to their data, faster) or whether it's truly about data quality. Because there is also value in the wisdom of the crowd, and overly rigid editing rules can impact data freshness.
That said, our current best way of doing this is to keep the Application (or other) workspace read-only, and then use Surveys and rely on Broadcast scoping as a mechanism to limit what surveys a user gets. This works, but it means that your end users will be limited to a one-by-one form-based update workflow, and miss out on other functionality from Ardoq such as Inventory for bulk updates.
Going forwards, we are exploring the use of the model to help dictate at least navigation and perhaps edit access. You can view and comment on these developments here:
How should I model multiple business units from an access perspective?
This is a much deeper topic, and it's covered partially in patterns for large enterprise modelling. Generally speaking, it will be the least amount of configuration overhead to keep everything in one workspace. This starts hitting a friction point in two ways:
The users from other business units MUST NOT see each other's data.
The only solution here is to break them into multiple workspaces.
The users from other business units can see each other's data, but now they're suffering from context bloat.
It's absolutely worth being clear on what camp you fall into, and generally we see most customers fall into the second camp (which also aligns with our principle on open defaults).
Situation 1: Users in different business must STRICTLY NOT see each other's data
We handle this today through separate workspaces as shown below.
This currently comes with a few challenges:
The challenge for 1a has largely been addressed with the Access Overview:
This approach doesn't come without its costs, but we are well aware of pain points. We are currently prioritizing improvements around metamodel management and "navigating to your data" faster to mitigate these issues.
Situation 2: Users in different business CAN see each other's data, but now they're suffering from context bloat
In this scenario, you have a choice:
Follow the structure for Situation 1 above, accepting the costs that come with it. This is generally not recommended, as it won't actually reduce the amount of context bloat your users experience and it comes with administrative overhead.
Keep everything in a single workspace (e.g. a single Applications workspace), but model data ownership of your your business units using one of our recommendations for organizational modeling: https://help.ardoq.com/en/articles/43939-organizational-modeling-patterns.
We also recommend you to read the article at the top of this section on large enterprise modeling.
This reduces the problem to "how can you reduce the context bloat that your users see". One approach to this is using viewpoints (e.g. using a viewpoint which is based on Organizational unit and opens the applications owned by that organizational unit, and then educating your user base to navigate via this viewpoint). However, we understand that this may not scale well either -- future improvements here are part of our roadmap.
When will Ardoq have component-level permissions?
We don't currently have plans to; in fact, we built it and had a closed testing round with customers, but we don't see it as a viable path forwards for a few reasons:
1. In many cases, this need is driven through a range of needs, only a few of which are permissions requirements:
"I want to hide things which are unrelated to these groups of users, to avoid accidental mis-modelling."
I want to hide things which are unrelated to these groups of users, to simplify the UI.
I want to partition my workspace into multiple teams or business units.
I want to tightly control who can edit which components for data quality reasons.
☝️ many of these are either much broader than "permissions", or are trying to solve a problem using permissions which is better solved in other ways (e.g. Personalization).
2. It's a deceptive shortcut
As shown below, even if you could assign fine-grained permissions below the workspace level, you don't remove all the other needs that workspaces fill:
How do you select which data should be included in a report?
How do you select which data should be included in a survey?
How do you select which data should be shown in a visualization?
Slowly you work your way back to a requirement to have a "bucket" for your data, which is referencable by the rest of the platform.
That's just workspaces all over again!
For this reason, we feel that many of these needs emerge from trying to use configuration to work around the platform limitations of workspaces (e.g. metamodel sychronization, better navigation, personalization, etc).
We would prefer to improve those platform limitations instead.