An Application Object (AO) is the unit in which OutSystems measures how large a customer’s applications are. OutSystems’ support documentation defines it as “a measurement of the complexity of your applications on the OutSystems platform”: each screen, entity or database table, API method and custom-defined Event in the apps counts as 1 AO, and AOs are counted the same in OutSystems 11 (O11) and OutSystems Developer Cloud (ODC) except where the page notes otherwise.[1] The pricing page describes the same unit as “the sum of the screens, database tables, and API methods across your apps” and says a typical medium-sized app is about 150 AOs.[2]
AOs matter because they are one of the two main quantities of a subscription, alongside end users. The Master Subscription Agreement says that “Application Object”, as used in an Order, has the meaning given on the OutSystems Support page on Application Objects, so the counting rules summarised here are contractual in effect and can move when the page is updated.[3] The page used for this article is dated 2026-09-06, which is the effective date given to the catalog rows.[1]
Editions
AOs apply to both platform lines. Subscriptions “typically include rights to run applications up to a specified number of AOs, with options for upgrading AO capacity that vary by subscription”.[1] In ODC, additional AO capacity is sold in packs of 150 AOs; the fair use page states that each additional 150 AO pack purchased gives each stage extra compute capacity, 5 additional compute instances without High Availability or 10 with High Availability.[4] The catalog row is Additional 150 AO pack (ODC). The price of a pack is not published. For O11 the page says AO limits are shown in the Customer Portal and usage per runtime in Service Center.[1]
Metrics
The metric is Application Object (AO). The page lists what counts under four headings, then adds general scenarios.
Screens
Web screens, email screens and mobile web screens each count as 1 AO. Web blocks, which live inside screens, do not count; neither do tabs and pop-up windows in Reactive web apps, which are part of an existing screen, nor tooltips. Tabs and pop-up windows created as distinct screens in Service Studio, as in traditional web apps, count as 1 AO for each screen.[1]
Entities and database tables
Entities created in OutSystems, both normal and static, count as 1 AO each, and so do entities imported from external databases (a table or a view), entities using local storage for mobile apps, and static entities included in a library. Tables created by the platform itself, such as the Users table that stores end user information, do not count. O11 entities that are imported into ODC through Data Fabric do not count.[1]
API methods
Each REST API method created or consumed within an app or library counts as 1 AO, as does each method created or consumed through SOAP web services. In ODC, each API method imported through Data Fabric (the page names SAP BAPIs, SAP OData Deep Inserts, Search Services and MCP tools) counts as 1 AO, and each API method consumed through AI Models counts as 1 AO. Each SAP BAPI method consumed in O11 through Service Studio counts as 1 AO. API methods within C#-based extensions do not count, and neither do REST API methods exposed in one platform and consumed only in the other.[1]
Events
Each custom-defined Event created in ODC counts as 1 AO. Events in O11, block events and lifecycle events do not count.[1]
Counting and floors
Differences between OutSystems 11 and ODC
The documented differences are these.[1]
| Item | OutSystems 11 | OutSystems Developer Cloud |
|---|---|---|
| Custom-defined Events | Do not count | Count as 1 AO each |
| Published libraries not referenced by any application | Count | Do not count |
| Multiple versions of the same library | Not addressed | Only the version with the most AOs counts |
| Library used across several portfolios | Not addressed | Counts once |
| Entities imported across platforms through Data Fabric | n/a | O11 entities imported into ODC do not count |
| API methods imported through Data Fabric | n/a | Each counts as 1 AO |
| API methods consumed through AI Models | Not addressed | Each counts as 1 AO |
Other counting scenarios
Within one runtime environment, each entity and each API method counts only once, even when several apps use it. Disabled applications continue to count until they are deleted. Components sourced from the Forge marketplace may also count, and the Forge page for each component gives detail. For libraries, the count includes all API methods and static entities in the library even if not all are referenced.[1] In ODC, all selected entities of a connection contribute to the AO count if the connection is referenced in an app: the page’s example is a connection with 50 Salesforce entities selected, of which only one is used, which counts as 50 AOs.[1]
Practical consequences, offered as commentary rather than OutSystems statements, are that selecting only the entities an app needs when configuring a connection, and deleting rather than disabling retired apps, are the two documented ways to reduce an AO count without changing functionality.
AO limits and production runtimes
The licensed AO capacity “only applies to production runtimes”. Development and non-production or QA runtimes allow unlimited AOs but cannot be used for running apps for production use.[1] The Master Subscription Agreement backs this with a restriction on deploying or operating applications in production using a non-production environment.[3] With a single production runtime, the customer may run up to the licensed AO capacity in it. With several production runtimes, it may run up to the licensed total across all of them, and the AO usage of each production runtime is summed to find the total.[1] For ODC the AO count and consumption across production stages are shown in the Subscription section of the ODC Portal.[1]
Worked example (commentary)
The following arithmetic applies the page’s rules to an invented estate. A customer has two production runtimes. In the first, an app has 40 screens, 25 entities and 10 REST API methods (75 AOs); a second app in the same runtime uses 10 of the same entities, which count once. In the second production runtime, a library has 30 REST methods and 5 static entities (35 AOs). The total is 110 AOs, to be compared with the licensed total, whichever runtime they sit in. A development runtime with 400 AOs adds nothing, because AO capacity applies to production only. The example uses no OutSystems figures except the counting rules.
Virtualization and partitioning
Not applicable: AOs describe application content, not servers or processors. The separation that matters is between production and non-production runtimes, described above and in OutSystems end users, runtimes and editions.
Cloud and self-managed
The AO rules are the same for OutSystems Cloud and self-managed customers. The difference is verification: self-managed customers cooperate in a remote usage verification once per calendar quarter, and the Subscription Compliance Terms say it is not needed in an OutSystems Cloud hosted environment.[5] If usage exceeds the licence, OutSystems may invoice the excess at the then-current list price from the date of first unlicensed use.[5] See OutSystems subscription compliance and contract terms.
Programs
No programme is specific to AOs. The Subscription Compliance Terms apply to AO overuse like any other excess usage.[5]
Out of scope
This article does not cover AO prices, which are not published, or the AO count of any particular Forge component. It does not cover end users, runtimes and compute resources, covered in OutSystems end users, runtimes and editions, or the sources that define Users. The AO page is rendered by script and the counting rules above reflect its content as read on 2026-10-07; a later edit of the page may change them.