- Home
- Services ▼
ServiceNow View all ServiceNow services →Other ServicesNot sure where to start? Talk to an expert →
- Industries ▼
- Resources ▼
- Company ▼
- Contact
Building on ServiceNow is easy; building something that still works after three family releases is not. The difference is scoping discipline, data model design, and refusing to reach into the global scope because it is quicker. Ramisun builds custom scoped applications on App Engine with the architecture decisions that keep them maintainable — and certifiable, if the Store is where you are heading.
A scoped application is a custom application built inside its own namespace on ServiceNow App Engine, with its own tables, business logic, roles, and API boundary. Scoping isolates the application from the global scope and from other applications, which is what makes it upgrade-safe, independently deployable, and eligible for ServiceNow Store certification. Ramisun designs the data model, security model, and API surface up front, because those three decisions determine whether the application is still maintainable in three years.
"Anything you can build in the global scope in a week, you can regret for a decade. Scoping is not bureaucracy, it is the thing that lets you upgrade."
Tables, relationships, and extension points designed before code.
Own namespace, own roles, own API boundary — never reaching into global.
Role model and record-level access designed alongside the data model.
Built to pass ServiceNow security review if Store publishing follows.
Almost always for architectural reasons decided in the first fortnight.
Figures shown are industry benchmarks and illustrative placeholders — replace with sourced, dated statistics before publication.
Architecture first, because the first fortnight decides the next three years.
Users, process, and the smallest version worth building first
Data model, scope boundary, role model, and API surface agreed
Two-week increments with working software demonstrated each close
ACLs, roles, and data handling reviewed against platform standards
Update sets, environment promotion, and production release
Enhancement, support, and certification if Store publishing follows
Both work on day one. Only one survives the family release.
| Area | ❌ Typical Approach | ✅ Ramisun Approach |
|---|---|---|
| Namespace | Global scope, colliding with everything else | Own application scope with a clear boundary |
| Upgrade Safety | Reviewed and often reworked every family release | Isolated from platform changes by design |
| Data Model | Tables added as needed, relationships implicit | Designed up front with explicit relationships |
| Security | ACLs added after users report seeing too much | Role and record-level access designed with the model |
| Deployability | Manual update sets with unclear dependencies | Versioned application file, cleanly installable |
| Store Eligibility | Not certifiable without a rebuild | Certification-ready architecture from day one |
| Maintainability | Only the original developer can safely change it | Documented, conventional, and handover-ready |
Each capability maps to real delivery work — with outcomes and the Ramisun approach.
The data model is the decision you cannot cheaply reverse. We design tables, relationships, and extension points before writing code, and we extend platform tables only where that genuinely serves the application rather than saving a week.
Everything we build lives in its own application scope. It is slightly more work at the start and it is the single decision that most reliably prevents the application becoming a liability at the next family release.
A custom application people avoid is a custom application that failed. We build with UI Builder and Workspace so the interface fits the task, and we test with real users before assuming adoption.
Access control designed after the fact is access control that leaks. We design the role model alongside the data model, and we build to the standards ServiceNow security review applies whether or not certification is the goal.
Few applications are useful in isolation. We design the integration surface as part of the architecture so connecting the application later does not require reopening its internals.
If publishing to the ServiceNow Store is a possibility, the architecture decisions that make it achievable are made in week one. Retrofitting certification readiness is substantially more expensive than building for it from the start.
The decisions that determine three-year cost are all made in the first fortnight.
Every application we build lives in its own scope with an explicit API boundary. This is an architecture rule rather than a preference, because global-scope shortcuts are the most reliable source of future upgrade pain.
Tables, relationships, and extension points are designed and reviewed before build starts. It is the decision that is most expensive to reverse and the one most often made by accident.
Roles and ACLs are designed alongside the data model and built to the standards ServiceNow security review applies, whether or not Store certification is planned.
Fixed-length increments with a demo at each close. You judge real software rather than a status report, and scope conversations happen while they are still cheap.
Where a platform capability already does the job, we use it. Custom code is written where it earns its keep and documented where it exists.
Source, documentation, and a named internal owner at handover, with hypercare to make the transition real. The goal is your team maintaining it, not a permanent dependency on us.
Bring us the problem rather than the specification. We will come back with an architecture, a scope, and a first increment you can judge.
"Anything you can build in the global scope in a week, you can regret for a decade."
A scoped application lives in its own namespace with its own tables, roles, and API boundary, isolated from the global scope and from other applications. That isolation is what makes it upgrade-safe, independently deployable, and eligible for Store certification. Applications built in the global scope tend to require review and rework at every family release.
Configure the existing module wherever it genuinely fits, and we will tell you when it does. Custom applications are appropriate for processes with no reasonable platform equivalent, not for avoiding the effort of learning one. We assess that during scoping rather than assuming a build.
Custom application development generally requires App Engine entitlements, and the tier affects table counts, users, and available capabilities. Licensing changes between releases and by agreement, so we confirm your specific position with ServiceNow before designing anything that depends on it.
Only realistically if it was architected for that from the start. Store certification imposes structural, security, and upgrade-safety requirements that are substantially cheaper to build for than to retrofit. If publishing is even a possibility, tell us in week one and we will design accordingly.
A focused first release typically runs 8–14 weeks from discovery to production, delivered in two-week increments with working software at each close. Scope discipline is the main variable, which is why we push hard on identifying the smallest genuinely useful first version.
You do, from the first commit. At handover you receive the application source, architecture documentation, a runbook, and a walkthrough, with a named internal owner agreed before we close. Hypercare follows so the handover is tested rather than assumed.
Every quarter without the right platform is revenue and efficiency left on the table. Tell us your challenge — get a real plan back, not a sales script.
A ServiceNow consultant will reach out within one business day to schedule your session.