I'm building a solution and as part of this, I'm trying to make a easy to show interactive environment.
One of the things I was thinking about was setting up Delegated development on my Personal Developer Instance.
It became apparent to me that I didn't understand Application Administration compared to Delegated Development, at least not how the docs say.
If you're coming across this and want to know the difference, here it is.
- Application Administration is the functionality to restrict standard administrators from accessing a scoped application. Think Human Resources Service Delivery. You may not want global admin's mucking up columns on their tables, business rules, flows, etc.
- Delegated Development is the functionality to invite and allow others to build automation within a specific scope.
I want to take a few moment and dive into each a little more as my understanding now, may help me later when.
Application Administration
This was not what I was looking for before, but let's talk about it, and how you can set it up.
You need a scoped application to get this, and then once you look at the scoped application you'll notice a checkbox next to Application Administration that looks like it's a simple check. It is, but you wont be able to save that record until you have a role with the Application Administrator of true.
Here's a quick and dirty checklist to try it out.
- Create a scoped application
- Change your current scope to the new scope.
- Create a role.
- On the list view of the role, show
Application Administrator
- Set
Application Administrator
to true - Go back to "My company applications" and click the left-side of the tile to open the application's details.
- Check the box.
What did this just do? Well, if you don't have this role, you wont be able to mess with anything inside of that scope.
Delegated Development
This was what I was looking for, but after seeing it, I'm not user it's what I need.
Let's say you wanted to let some folks not on your team build on ServiceNow in a way that is separated by scope from you. This would be how to achieve that. Here's a quick list of steps to try it out.
Create a scoped application
In the related links you might see "Manage Collaborators" from the App, or in Legacy studio under the file menu, you can see the same.
Click on that, a Modal will appear with a invite field, and level.
- So it appears you can pick anyone
- The level's are limited to editor and owner. Owner should include all access, and it nearly does. It's missing the scripting option.
- Pick a user, or better create a user with no roles, then pick that person.
- Pick owner
Once that's submitted, you'll probably notice something about the request being auto rejected. This is... by design. I forgot to mention you will need to ensure the group,
App Engine Admins
need's to have some folks in it who can approve these tasks.Start over, at step 3. Welcome back.
Now you might be wondering what task did this create? It made a
sn_collab_request_dev_collab_task
record and an approval against it to the groupApp Engine Admins
.You can look up the flow, it has over 30 steps. If you approve the request the user will be given over 20 roles (given you gave them "owner" access).
Now if you have them or impersonate them to see what they can do, you can notice you can see all the appropriate buttons in legacy studio and the new ServiceNow studio to create flows, business rules, portal widget etc. However, you may notice, they can't edit or create any scripts in those records.
Stop impersonating them and go back to where you invited them, that modal. You'll see they are listed as a collaborator, go ahead and change their access.
See the options, there's a "Allow Scripting" near the bottom.
Further Reading and thoughts
These two features might be a bit weird to understand. Hopefully this helped. Thanks John Dahl for letting me bounce these ideas around with you, that helped me get to this understanding faster.
If you'd like to read more on this, these are the links I was using to try to understand it.