Is it recommended to grant "delegated_developer" role to Workplace Maintenance managers?

[Mollie V]

Hi community,

We are working to implement workplace maintenance with our global facility team so they can use maintenance case management for managing their day-to-day preventive maintenance activities such as security inspections, etc.

When creating case templates and workplace service records, users need to switch scope applications, otherwise the templates and services can't be associated to the maintenance plan. Without a "developer" type role, they are not able to do this. Currently, these are the roles were granted that allows the team to manage plans, services, and cases.

• sn_wsd_maintenance.admin
• sn_wsd_case.admin

My questions are, is it recommended to grant non-developer users "delegated_developer" role so they can switch applications? What are the implications or risks this would cause? Is there an alternative to not granting the team the developer role?

My concern is opening up access to modules that are unrelated applications and configurations to the team. We want the team to be self-supporting without needing an admin to create case and service templates for them each time they need one.

Thanks in advance for your kind support and expertise.

Mollie

[lastreaction122]

---

@Mollie V wrote:

Hi community,

We are working to implement workplace maintenance with our global facility team so they can use maintenance case management for managing their day-to-day preventive maintenance activities such as security inspections, etc.

When creating case templates and workplace service records, users need to switch scope applications, otherwise the templates and services can't be associated to the maintenance plan. Without a "developer" type role, they are not able to do this. Currently, these are the roles were granted that allows the team to manage plans, services, and cases.

• sn_wsd_maintenance.admin
• sn_wsd_case.admin

My questions are, is it recommended to grant non-developer users "delegated_developer" role so they can switch applications? What are the implications or risks this would cause? Is there an alternative to not granting the team the developer role?

My concern is opening up access to modules that are unrelated applications and configurations to the team. We want the team to be self-supporting without needing an admin sound to create case and service templates for them each time they need one.

Thanks in advance for your kind support and expertise.

Mollie

---

Granting the "delegated_developer" role to non-developer users like Workplace Maintenance managers can have significant implications. While it enables users to switch application scopes and create or manage templates independently, it also increases their access to sensitive system areas.

This expanded access could expose unrelated modules or configurations to users who may lack the expertise to handle them safely, potentially leading to accidental changes or errors in unrelated applications. Additionally, this approach could increase the risk of configuration drift or unintended system modifications, which might require more oversight from system admins to prevent issues.

Instead, consider alternatives like creating a custom role with only the necessary permissions for switching scopes and managing maintenance-related templates and services. This approach provides the needed functionality without granting excessive access.

[Venkumahant]

Granting the delegated_developer role to Workplace Maintenance managers in ServiceNow depends on their specific responsibilities and organizational needs. Here's a breakdown to help decide:

What Does the Delegated Developer Role Allow?

The delegated_developer role provides access to low-code/no-code tools within App Engine Studio, enabling users to:

Create and modify applications.

Build workflows, interfaces, and automations.

Customize tables, fields, and other application components.

Key Considerations:

1. Job Responsibilities:

If Workplace Maintenance managers are responsible for creating or managing custom applications related to their domain (e.g., room booking apps, maintenance request workflows), the delegated_developer role can empower them to innovate without relying on IT.

If their role is operational and focuses on using ServiceNow rather than building/customizing applications, this level of access may be unnecessary.

2. Skillset:

The role is suitable for users with basic knowledge of ServiceNow and application development. Without proper training, granting this role may lead to unintended changes or system inefficiencies.

3. Security and Governance:

ServiceNow encourages a controlled approach to role assignments. Granting development privileges should align with your organization's governance model to avoid unintentional disruptions or security risks.

4. Alternative Roles:

If the managers need limited customization capabilities (e.g., configuring reports, managing dashboards), roles like itil_admin or specific application-level roles might be more appropriate.

5. Best Practices:

Train users before granting the delegated_developer role.

Use ServiceNow’s Governance, Risk, and Compliance (GRC) or DevOps tools to monitor and control application changes made by delegated developers.

Recommendation:

Grant the delegated_developer role to Workplace Maintenance managers only if they have a defined need to build or manage applications and adequate training.

For simpler needs, consider granting roles with more restricted permissions.

Would you like a compari

son of specific roles or further guidance on governance?

[Mollie V]

Thank you @lastreaction122 and @Venkumahant for your suggestions. I'd like to explore creating a specific role to these workplace managers that would allow them to switch application scopes but not allow them to change any configuration, scripts, etc. Do you have any further guidance or references I can review?

Best,

Mollie