Forum Discussion
Helper IOrg Apps Governance Strategy question
Hello, our organisation has traditionally used roles to control who has access to reports by granting a viewer role to a users for a workspace. The issue with this approach is that it's all or nothing. Viewers can see ALL objects in the workspace, and sometimes we want more subtlety that that. We might want to share specific reports with one set of users, and other reports with another set.
We were looking at Workspace Apps, but since Org Apps are now GA, this seems to offer even more options.
Within our business, we have restrictions which block certain business area users from seeing information from other busieness areas. Therefore it's important that we are careful with who sees what information.
At present, each business area gets a DEV, TEST and PROD worskpace and we have used a VIEWER and CONTRIBUTOR AD group per workspace to manage access. This means 6 AD groups. With this new approach of using Org Apps, we can do away with the VIEWER AD Groups. However, we would need to grant users access to the Org Apps we create. This could potentially be 1 or several Org Apps per workspace, and possibly several audiences within each Org App! If we go with AD groups for controlling access to these, we'll spend our lives creating AD groups and adding and removing users. This is why I am inclined to go the route of simply adding users directly to the Org Apps or applicable audience within an org app. Have I missed a potential risk to doing this? Is there a better way to do this?
Thank you
Yes, there is a real risk to adding users directly to Org Apps. It breaks your joiner/mover/leaver process, so when someone leaves or changes team their access is not automatically revoked, and you also lose the clean audit story that Entra ID groups give you.
The pattern that keeps group sprawl under control without going back to direct assignments is Audiences inside a single Org App. You create one Org App per PROD workspace and then add as many audiences as you need for the different report groupings, each audience mapped to one Entra ID security group. That way you get granular per report visibility with a small, stable set of groups.
A couple of extras that help: only publish the Org App from PROD and keep DEV and TEST workspace only for developers, and if your HR attributes are clean you can use dynamic Entra ID groups so membership updates itself.
If this helped, a thumbs up and accepting the solution would be appreciated.
Best regards,
Shai Karmani
2 Replies
- Shai_Karmani
Super User
Yes, there is a real risk to adding users directly to Org Apps. It breaks your joiner/mover/leaver process, so when someone leaves or changes team their access is not automatically revoked, and you also lose the clean audit story that Entra ID groups give you.
The pattern that keeps group sprawl under control without going back to direct assignments is Audiences inside a single Org App. You create one Org App per PROD workspace and then add as many audiences as you need for the different report groupings, each audience mapped to one Entra ID security group. That way you get granular per report visibility with a small, stable set of groups.
A couple of extras that help: only publish the Org App from PROD and keep DEV and TEST workspace only for developers, and if your HR attributes are clean you can use dynamic Entra ID groups so membership updates itself.
If this helped, a thumbs up and accepting the solution would be appreciated.
Best regards,
Shai Karmani 
FabScone75Thank you Shai_Karmani . Just a final question for you. When a report developer wants to share a report with a stakeholder to assess its suitability (eg in the test workspace), would you recommend that this report be shared directtly with the stakeholder(s) in question? Or do we have a viewer AD group for the test workspace only? How do we manage that requirement, whilst retaining good governance processes.