Enable your teams to scale better with fine-grained settings and permissions for Digital Experience Management

As organizations grow, easy manageability and scalability is vital to advancing automation efforts. The problem that many enterprises face is that existing role-based permissions and related settings often aren’t flexible enough to fully enable teams to easily scale their operations and tooling.

We’re excited to tie two recent announcements together, namely, our new settings framework and our new resource-oriented permissions framework. When combined, the settings and permissions framework takes the burden off your administrators and helps your teams by providing them with self-service configuration and fine-grained permission management for better scaling.

The new settings and permissions framework takes the burden off your administrators and enables your teams to scale better

To demonstrate the main benefits of our settings conversion efforts, let’s look at some of the recent changes and show you how you can now leverage them via the Dynatrace web UI as well as the API.

Levels, defaults, and overrides

The new settings framework makes it easy to configure settings at multiple levels. Take, for example, data privacy settings, which used to be available only at the environment level. This meant that your most confidential application dictated the privacy settings for all your applications, which impacted the visibility of applications for which privacy concerns aren’t applicable.

That’s why we’re excited that with Dynatrace version 1.220, these settings are part of the new settings framework, allowing you now to set all application-relevant privacy settings not just at the environment level but also at the application level.

This means that Dynatrace administrators can now configure companywide defaults for settings at the environment level, while your teams can autonomously override these defaults for each individual application (as shown in the image below), depending on their privacy needs and requirements.

Application privacy settings override environment-level settings

You can override environment-level defaults for privacy settings at the application level or reset them and navigate back to the environment-level settings using the Environment link.

Environment settings and security policies solve the all-or-nothing problem

There are some settings that you might not want to define at the application level. In the past, assigning individual settings that were only available at the environment level required your administrator to provide users with near-full access to all other settings at this level.

With the new settings and permissions framework, this isn’t necessary. (Read more in our blog post about security policies, which define what individual users are allowed to see and which settings they’re allowed to edit.) This frees Dynatrace administrators from the burden of balancing such settings for individual teams while not becoming a bottleneck that prevents your teams from scaling.

Let’s look at how your administrator now can easily delegate certain environment-level settings to individual teams, providing them with the right amount of autonomy and, thereby, helping your company and teams to scale better.

The following example shows how creating a security policy for a setting and then binding this policy to a user group now allows your administrators to delegate the configuration of settings.

In this example, we created a policy called Application Developer, which provides access to the privacy (builtin:preferences.privacy) and user experience score (builtin:rum.user-experience-score) settings, making only the required settings available to particular groups and users, solving the problem of all-or-nothing access.

Creating a new policy “Application developer” and defining which settings can be accessed via the policy statement

The first image below shows the binding of the Application developer policy, which grants permission to two defined settings (see the second image), to the Application developer user group.

Binding a policy for settings configuration to a user group

Settings after granted permissions

Previously, teams needed to contact their administrators to change such environment-level settings. Now, by creating and binding the right policy to a user group, all users in the group can easily and autonomously configure these settings themselves.

What about the API?

A big advantage of the new settings framework are the new generic Settings API endpoints that you can now use whenever any settings based on the new framework are added to Dynatrace. You can retrieve the list of settings or edit individual settings, among other operations. You can automate setting up a new environment and easily transfer settings between environments, say, from staging to production.

The new settings embody our API-first mantra and promote automation not just for administrators but also for individual teams.

We’ve responded to our biggest enterprise customers who, in the past, have requested and needed API endpoints for practically all settings—the new settings framework now offers these API endpoints right out of the box.

Dynatrace screenshot API endpoints

The following illustration shows you how the API can implement the same new policy-driven permission model described in the UI-based approach above. Simply compare the output of the curl request with the previous illustration of setting up a policy via the Dynatrace web UI.

Dynatrace code snippet

Share your feedback and help us shape more settings conversions

Customer feedback is paramount for us in providing the best experience to our users. Therefore, we invite you to tell us more about your most needed improvements to settings that haven’t yet been converted or haven’t already been discussed in our Community forums. So don’t miss out on the chance to team up with us, and start contributing in the Dynatrace Community now.

Stay updated