If your organization runs ServiceNow, you have probably seen applications described as native or Built on Now. The label matters because it tells you where the application runs, where its data lives and who governs it. A native app runs inside the instance you already secure and administer. An integrated app runs somewhere else and exchanges data with ServiceNow through connectors.
This guide, refreshed for 2026, explains what Built on Now means, why it matters to platform owners and security teams, and what to check before you add a native application to your instance.
What does Built on Now mean?
ServiceNow lets partners build applications directly on the Now Platform and sell them through the ServiceNow Store. In 2020 it introduced the Built on Now designation to mark applications that are developed natively on the platform rather than simply connected to it.
In ServiceNow's terms, a Built on Now application is a scoped application built on the platform that can be distributed in full from one instance to another as a scoped application. In plain language, everything the app needs lives inside ServiceNow. There is no separate server holding your data and no external login.
The designation helps buyers tell apart two kinds of products on the Store: those that are sold for ServiceNow but run elsewhere, and those that are built inside it using its workflows.
Why does native matter to ServiceNow customers?
Security and governance you already run
A native app inherits the controls your security team has already approved: single sign on, roles and access control lists, encryption and audit history. Store applications also go through ServiceNow's certification review before they are listed, which adds a layer of scrutiny.
One data model
Because the app uses the platform's tables and data model, its records connect directly to the rest of your instance. A contract can reference the configuration item it covers, the vendor in your vendor records and the request that started it, without syncing between systems.
Familiar experience
Native apps use the same portals, workspaces, forms and mobile experience your users already know. Training is shorter and adoption tends to be easier, because people work where they already work.
Upgrades and administration
Your platform team manages a native app with the tools it uses for everything else on ServiceNow, including update sets, instance upgrades and testing. There is no second vendor environment to monitor.
What should you check before installing a native app?
Not every product that mentions ServiceNow is built on it. These questions separate the two:
- Is the vendor a ServiceNow technology partner with applications listed on the Store?
- Is the user interface built with platform components, such as Service Portal, Workspace, mobile, forms and user interface pages?
- Does it use core platform functionality and business logic, such as flows, approvals and notifications, rather than its own engine?
- Do users reach it through ServiceNow, with no separate access system?
- Where does the data live, and does any of it leave your instance, for example for AI processing?
| Question | Native application | Integrated application |
|---|---|---|
| Where it runs | Inside your instance | On the vendor's own environment |
| Login | Your ServiceNow single sign on and roles | Often a separate account |
| Data | Platform tables in your instance | Copied or synced between systems |
| Workflows | Platform flows and approvals | The vendor's own engine |
| Administration | Your platform team | Your team plus the vendor |
Native and integrated applications compared from a platform owner's point of view.
What can the Now Platform support beyond IT?
ServiceNow started in IT service management, but the platform is a general workflow engine with a single data model. Organizations use it for employee requests, customer service, security operations, risk and compliance, and increasingly for procurement and contract work.
That makes it a natural home for work that crosses departments. A contract request, for example, touches the business, legal, procurement, security and finance. Running it on the same platform as IT assets and vendor risk keeps the whole process visible in one place. Read more about contract management on ServiceNow.
How does Aavenir fit?
Aavenir's apps, including Contractflow, RFPflow, Obligationflow and Invoiceflow, are built natively on ServiceNow and available on the ServiceNow Store. They run in your instance under your roles and audit history, and Aavenir AI inside each app, works within the same permissions. A person approves every AI result.
For organizations that do not run ServiceNow, the same apps are available as a standalone deployment. See built on ServiceNow for details on the native approach.
Does native mean no work for your team?
No. A native app still needs your own security review, a clear owner, configuration that matches your processes and testing with each platform upgrade. What it removes is the overhead of a second system: another login, another data store and another integration to maintain.
A good test during evaluation is to ask the vendor to install the app in a sub production instance and walk your platform team through it: which scoped tables it creates, which roles it adds, how it behaves after a family upgrade and whether any call leaves the instance. A native app should pass that walkthrough without surprises, and the answers give your security team what it needs for its own review.
The bottom line
Built on Now tells ServiceNow customers that an application lives inside the platform they already govern. That means familiar security, one data model and simpler administration. Check how an app is built before you buy it, and treat native as a strong starting point, not a replacement for your own review.