Setting up the permissions model - Best practicesThe Sweagle permissions model can go to a high level of granularity, but it is a best practice to start with a simple and transparent permissions model. At least at the beginning of the project. There are no limitations to add more granular permissions later on. Policies to roles, roles to users Although it is technically possible to assign policies directly to users, it is recommended to not do that as it makes the management of permissions more complex. As a best practice: assign 1 or several policies to a role (many to many) assign 1 or several roles to a user (many to many) Data path access by dimension Although it is technically possible to define access permissions at any level in the config data model, it is recommended to apply permissions at the level of the root dimensions or at maximum the first level in every dimension. As a best practice, we recommend to define a policy with "read access" and another policy with "edit access" to every dimension. Based upon that it is transparent to group "read access" and "write access" to specific dimensions in a role for every team or organization. As an example, let's say that team1 owns the configdata in dimension1 and 2, while they need to be able to view configData from dimension3 and they should not have access to dimension4 dimensionpolicyteam1 roledimension 1dim1 - read accessdimension 1dim1 - edit accessxdimension 2dim2 - read accessdimension 2dim2 - edit accessxdimension 3dim3 - read accessxdimension 3dim3 - edit accessdimension 4dim4 - read accessdimension 4dim4 - edit accessapprove changesx All users who have the team1 role assigned can now create and apply changes for dimensions 1 and 2, they have view-only access to dimension3 and dimension 4 will be hidden. These permissions are applied in the user interface, but also to any API tokens which are assigned to that same role.