need best practice recommendation

[Servicenow lear]

Dear All,

I’m in a bit of a challenging situation and would appreciate your insights.

Our team is currently facing significant bandwidth constraints, yet we frequently receive requests from individuals outside the platform team for access to our ServiceNow instances so they can develop solutions on their own.

While their intentions are good, most of them do not have prior experience with ServiceNow—just some exposure through online videos and they are part of devops and other software development background —which raises concerns around quality, stability, and long-term maintainability. At the same time, there is increasing pressure to unlock development access.

I’d like to know if others have encountered similar scenarios:

Do you grant admin-level access in lower environments and rely on guardrails?
How do you balance agility with platform integrity, especially when bandwidth limits the ability to perform code reviews or implement a BPE tool?

Given our current team size and workload, we cannot commit to code reviews or governance tooling at this time. I’m trying to determine whether opening up the instance for external development is advisable, or if there are alternative approaches we should consider.

Any recommendations or experiences would be greatly appreciated.

[Dr Atul G- LNG]

Hi @Servicenow lear 

yet we frequently receive requests from individuals outside the platform team for access to our ServiceNow instances so they can develop solutions on their own.

Atul:

This is a clear case of implementing Idea and Demand Management, where any individual or group outside the platform can submit a new idea or request for work. The platform team, demand board, governance board, or product owner then evaluates the idea and converts the approved demand into a project.

Providing direct access to external users is not a best practice. Your internal platform team should own the platform and be responsible for all development activities.

More than just a tool, you need to implement proper governance and a standardized process to manage this effectively.

[Servicenow lear]

Thanks for the response.

The 3 pillars of governance is already there.  However the mindset is still the same where in it is treated as tool just like anyother such as devops and expectation is to unlock and unblock development.  Unfortunately , the pressure is such if you cannot fdo it then we want to do it and then escalations and what not. So I am trying to understand if there has been or somewehre people outside of platform team are given access to lower instances because I am afraid then it will allow other parts of org to strart accessing it 

[SumanthDosapati]

@Servicenow lear 

Enabling Citizen Development is the first step.

Granting Admin access to non-ServiceNow individuals is not recommended. If you are using ServiceNow for your own organization (not a consulting or service-based company), the approach depends on your billing and cost-recovery model. If you cross-charge internal departments or cost centers, you can temporarily onboard external (contractor) ServiceNow developers when demand spikes. Ultimately, this depends on how ServiceNow is governed and consumed within your organization.

Accept the solution and mark as helpful if it does, to benefit future readers.
Regards,
Sumanth

[FrykiSen]

We’ve been in a very similar situation and landed on a model that gives teams autonomy without risking the core platform.

How we handle “external” development access

• We allow “delegated developers” to develop in a sub-instance.

• Development is done in  dedicated application scops (their own scope, not Global).

• Each scope has clear ownership: who is responsible for it, what it’s for, and what they’re allowed to touch is enforced through access rights on the scope level.

Guardrails that make this workable

• The platform team always has final approval before anything reaches production. Delegated developers never deploy directly to prod.

• All scoped applications are source-controlled in GitHub and follow a standardized CI/CD pipeline so that it is possible to see what has changed.

• Delegated developers commit changes to GitHub and create Pull Requests against the relevant repository. 

• The platform team reviews the Pull Requests.

• Once a PR is approved a change is created and once approved installed through our CI/CD process

This approach has worked well for us 🙂

Hope it can give some pointers!

This guide could give some pointers on ServiceNow github and ci/cd
https://developer.servicenow.com/blog.do?p=/post/cicd-pipeline-github-actions/