We have cases where developers from one team need to open a module in another team's application, but we do not want the developers to have permission to add the other team's application as a dependency to their own.

However, the current permission levels available for LifeTime roles require that users with 'Open and Debug' permissions for an application must have the ability to monitor and add dependencies from it.

We want our developers to be able to learn from each other's code, but we do not want them adding dependencies to entities or actions for which their application is not entitled. 

For example, applications that handle sensitive PII may have additional organizational or regulatory requirements on data isolation from other applications on the same environment. In our case, it may be perfectly safe for developers from different teams to view each other's code in lower environments when the data contained in lower environments is dummy test data. However, we do not want to risk non-sensitive applications referencing components of sensitive applications in a production environment.

While you can make entities and actions private in Service Studio, typical three-layer architecture splits a project into one or more applications, each with one or more modules that may inherit from each other. Making an action or entity public makes it public for every other module unless access to the containing application is restricted in LifeTime.

We take advantage of these features to isolate developer access, but doing so, currently, means that either developers cannot view their peer's code at all; or that platform administrators and team managers have to keep track of assigning and removing temporary 'preview' roles.