OUT — Objects
The OUT — Objects screen lists the distinct objects of a licence component that have been invoked at least once on a connected application. One line per (Application, Component, Object) triplet, with the friendly description carried on the row.
It is the object-side complement of OUT — Users / Roles: the same dataset, pivoted by what was used instead of who used it.
At a glance
Goal of the view
For each licence component on a connected application:
- What programs are actually used? Each row is a program the source system has invoked at least once. The headline component count in OUT — Components hides this granular distribution.
- Spot dead objects. Objects of the component that never appear here are unused — useful when deciding whether to keep them on the menu.
- Recognise the program with its friendly name. Description makes the dataset readable to a non-technical reviewer.
Columns
| Column | Source | What it tells you |
|---|---|---|
| Application ID | LOUT_APPS_ID — application identifier. Filterable. | The connected application. |
| Component | CPT_ID — licence component. Filterable, hidden by default. | The licence bucket. Used by the drill-down from OUT — Components. |
| Object | LOUT_OBJECT — technical object. | The program that has been invoked. |
| Description | JDEO_DESCRIPTION — friendly object label. | Human-readable label. |
Tips & best practices
- Filter on a Component + sort by Object — the full de facto surface of the component on the application. Audit checks are easier when the universe is bounded.
- An object that never shows up here is dead weight — confirm with the business and consider removing it from the menu structure.
- Cross-reference with Rights — Roles to see which role grants each object — a heavily-used object backed by a single tight role is the cleanest configuration.
- Use this screen to scope a per-object SoD analysis — start from the real usage rather than from the theoretical rights matrix.