Platform Overview and Application Design
What to know
Every ServiceNow instance is a single-tenant environment built on a shared table model: all data lives in tables, all configuration is itself stored in tables, and everything a user sees is generated from those records. As a designer you must understand application scope. A scoped application has its own sys_app record, its own prefix, and its own artifacts; a global application shares one namespace with the base system.
Know the artifacts an application owns: application menu and modules, tables and columns, forms and views, business rules and script includes, UI policies, roles, ACLs, properties, and scheduled jobs. Know that scope is chosen when the application is created and is painful to change later, so decide early.
Traps
- Assuming a scoped application can freely read and write global tables, or that global code can freely call scoped script includes. Cross-scope access must be granted; private script includes are not callable from other scopes unless their access is set to public.
- Confusing update sets with source control, or assuming an update set carries data records. Update sets carry configuration metadata.
- Designing for a single instance instead of designing portable artifacts that can be published and installed elsewhere.
- Forgetting that new custom tables need a prefix, a display value, and access controls before they are usable.
Worked example / rule of thumb
Before opening Form Designer, answer four questions: What scope, what table, who may read or write, and how will this ship? If the answer to the last question is 'it must be reusable or sold', build it in a scoped application with a unique prefix and its own menu.
Rule of thumb: configuration over customization - prefer tables, forms, flows, and properties to scripts, and keep custom code inside the application that owns it.