Are you still developing in the global scope?

[Chuck Tomasi]

I'm hearing more and more that a lot of people are still developing their solutions in the global scope despite all the great development advancements we've built in to the platform (e.g. Git integration, Studio, delegated development, publish/install, etc.). Our platform business unit has the vision that we should all be building using scoped apps. This includes new apps as well as extensions to existing applications (even in the global scope.) I'd like to know what's keeping you from realizing that vision. Examples may include:

• There is a scripting API that is not available to scoped apps
• Our requirements force us to use synchronous Ajax
• We are still on Eureka
• I love update sets!
• I just don't know enough about creating scoped apps (and that's OK.)

Specifics are always appreciated. Thanks!

[Chris Sanford1]

One thing that might help is if they had a way to easily retroactively move an application in the global scope to it's own separate scope. I support a lot of applications that were put in long before I joined my team, and since they were initially developed in the global scope, I'm kind of stuck in the global scope for them unless I want to rebuild the entire application.

[William Busby]

Sorry, one more thing. I recall Chuck T. mentioned about a year ago they were considering trying some type of migration tool but it's pretty tough to implement. I doubt it's even possible. Consider migrating to a scoped app if you ever need to do a major rewrite. It will be worth the effort down the road. My 0.02 dollars.

[William Busby]

These are just some of the benefits of scoped apps specific to the Jakarta release. Scoped dev has gotten much better since Helsinki, which wasn't all that time ago:

- Studio will automatically track app dependencies when your app uses something in another scoped app including the OOB apps developed by ServiceNow (the company)

- Most of the cross app ACL references are automatically done for you

- You get to choose whether another app, even global, which isn't really global, has access to read/write data to your app or leverage your script includes, widgets, etc.

- Another developer can't make changes to things created in your app unless they open your app. When in global I've had developers remove fields I was using in my global code and they didn't know they just broke my code until someone tried to use it. Pretty hard to trouble shoot if that's months later

- If you do open it up the cross-dependencies are automatically created but you may need to tweak them

As to synchronous AJAX - just wait until you start coding for the portal. The count of times it's an issue will increase exactly by one every time you try it

Finally as to global development:

- If your code isn't contained in functions (which was very common in older versions) your variables with the same names are all in the same scope and subject to contention like 'i' in 'for (i = o; i < array.length; i++) if executing simultaneously. Probably not something you'd like to happen

- It's impossible to find code that references that script include which you've discovered needs a complete rewrite. Good luck on figuring out what to include in regression testing major releases

I could list a dozen more things that I've been bitten by when multiple developers are coding with related components that changes can blow up. ServiceNow still does a sometimes poor job of showing the root cause in these cases.

[Chris Sanford1]

Funny, I just answered this yesterday, but my team lead finally got us working on our first scoped application at my company today. One thing that the team didn't like, is the complicated table names (that all begin with the scope name). The 'prefix' that's set in a property controlled by ServiceNow, was not an intuitive name for our organization. The studio helps make it less of an issue, since it's easy to look up the table name quickly, but easier to remember table names and scope names would be nice.

[William Busby]

I've heard the technology partner team has the ability to change your company prefix but I'm not sure whether it can or should be done after your environment has been in use. But if you're just starting you might want to ping them before you get going.

Ditto on the naming in general. I get the reasons, I just wish there was a way to alias the scoped names to something a little easier on the eyes. Minor irritation for all the benefits of scoping apps.