> For the complete documentation index, see [llms.txt](https://boza.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://boza.gitbook.io/docs/inventory/applications.md). # Applications Track and manage your organization's SaaS portfolio. The **Applications** page is the central inventory for software your organization has already classified. It separates managed applications from tools that have been marked unapproved. Newly detected tools have their own [Shadow IT](/docs/inventory/shadow-it.md) page so administrators can triage discoveries before they enter the regular inventory. *** ## In this section | Topic | What you'll learn | | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | | [Authorization Categories](/docs/inventory/applications/authorization-categories.md) | How approval and tracking status determine where an application appears | | [App Detail Page](/docs/inventory/applications/app-detail.md) | A walkthrough of a single app's header, status controls, property cards, and the Overview, Users, Costs, Documents, and Architecture tabs | | [Shadow IT Detection](/docs/inventory/shadow-it.md) | How Boza discovers unknown apps and how administrators triage them from the dedicated **Shadow IT** page | *** ## Choose the right view The page contains two tabs: * **My Apps** — approved applications and applications still under review. * **Unapproved Apps** — applications your organization has explicitly marked as unapproved. Use **Shadow IT** in the sidebar to review applications that Boza has only just discovered. Each tab provides a sortable, paginated table. Search by application name, then use the export button (upload icon, tooltip **Export data**) to download the current result set as CSV. The export follows the active tab, search, and filters rather than exporting an unrelated full inventory. A **Need attention** badge marks applications that have subscriptions with unassigned licenses; its tooltip says how many. Use it to find seats you pay for that nobody holds. ## Filtering Click **Filter** to open the filter panel. Find a filter by name in the left pane, then choose its values on the right. Filters are grouped:
Application filter panel showing ownership, organizational, and security and compliance filters

Combine ownership and organizational filters with security criteria to create a focused application view.

* **General** — Category, Discovery Source, Hosting Type, Lifecycle Status, Domains, Vendor, and Custom Field. * **Owners / Teams** — Admin, Super Admin, Budget Owner, Team, Organization, and Group. * **Security & Compliance** — Need Attention (unassigned licenses), GDPR Compliance, Security Level, Criticality, and SSO/MFA configuration and enforcement. **Group** lists the groups synchronized from Google Workspace or Microsoft Entra ID. **Custom Field** lets you pick one of your own custom fields and then its values; values within one field are combined with OR, separate fields with AND, and **Not Provided** finds applications where the field is empty. The **Filter** button shows how many filters are active, the first active filters appear as chips you can clear individually, and **Clear all** resets the panel. Selections are kept in the page address, so a reload or a shared link restores the same view. Filters can be combined. For example, select an Organization and **MFA Enforcement** to find critical gaps within one part of the business. Security and compliance filters use the fields recorded on each [app's detail page](/docs/inventory/applications/app-detail.md). The export button produces a CSV of exactly what the filtered table shows. ## Bulk Actions Tick one or more rows and a selection bar appears at the bottom of the window. It stays on screen however far you scroll, and the selection is kept while you sort or move between pages, so you can build it up across the whole list. The count on the left tells you how many rows are selected, and the **×** on the right clears them all. * **Approve** / **Unapprove** — change approval status. * **Track** / **Untrack** — toggle usage and cost monitoring. The button reads **Track** when every selected application is untracked, **Untrack** otherwise. * **Unapprove & Untrack** — do both in one step. * **Assign Admins** — opens **Assign owners in bulk**: add a Super Admin, Admins, Budget Owners, or Access Reviewers to every selected application. Existing owners are kept, except that a new Super Admin replaces the current one. * **Merge** — combine two or more entries that are the same application. Admins only; greyed out below two selections, with the reason in a tooltip. * **Delete** — remove the selected apps after a confirmation.
Applications list scrolled to the bottom with two rows selected and the selection bar showing the bulk actions

The selection bar follows you down the list.

Approval and tracking are separate controls. For example, an application can be unapproved but remain tracked while your team investigates it. ## Adding an Application Administrators can click **Add New App** to add software that was not discovered automatically, including an internal or on-premise tool. The wizard uses a two-pane layout: browse the catalog by category or search it on the left, then follow the steps for the selected application on the right. 1. **Choose an application** — browse the catalog by category, search it, or create a custom entry. 2. **Enter the details** — provide the name, description, access URL, category, and domain as required. 3. **Record security posture** — capture GDPR, SSO, MFA, and IT-approval information. 4. **Assign ownership** — select a Super Admin, Budget Owner, and application Admins. A confirmation screen closes the wizard, so you can add another application without reopening it. After creation, complete any remaining ownership roles from the app detail page. In particular, assigning an **Access Reviewer** determines who receives that application's review in an [access review campaign](/docs/user-management/access-reviews.md); if none is assigned, Boza can fall back to the Super Admin. ## Merge Duplicate Applications The same tool can reach your inventory more than once: discovered through your identity provider, created from an invoice under its legal name, and added by hand. Each copy carries part of the picture, so the cost and the user count are split. Boza raises likely duplicates at the top of the list, and administrators can merge them. ### Review a suggested duplicate When Boza finds a candidate, a banner appears above the table: **N possible duplicate applications found**. 1. Click **Review**. The dialog explains why the pair was flagged, for example that the names match once punctuation and company suffixes are removed. 2. Choose which entry **survives**. Boza proposes one, and you can select the other instead. 3. Read **What will happen**. It counts the users, licences, subscriptions, monthly cost, owners, activity events, and custom fields that would move onto the surviving entry. 4. Decide: * **Merge Applications** performs the merge. * **Not a duplicate** dismisses the pair, and Boza stops suggesting it. * **Decide later** closes the dialog and leaves the suggestion in place. Boza only suggests a pair when the two names match exactly after normalisation. It stays silent when the evidence is ambiguous, so an empty banner means no confident candidate, not a failed check. ### Merge applications yourself Select two or more rows in **My Apps** and choose **Merge** from the selection bar. The same dialog opens, whether or not Boza flagged them: pick the entry that survives under **Keep**, and everything from the others moves onto it. The warning names every entry that will be removed, so read it before confirming. Step-by-step, with screenshots: [Merge duplicate applications](/docs/tutorials/merge-duplicate-applications.md). ### What a merge does * Users, licences, subscriptions, owners, activity, contacts, and vendor links move onto the surviving application. * Where both entries hold the same row, for example a user who appears on each, it is kept once rather than duplicated. * The surviving application keeps its own settings and history. Details it is missing, such as notes, category, lifecycle, or domain, are filled in from the entry being removed. Tags are combined. * Later syncs, licence imports, and invoices attribute their data to the surviving application instead of recreating the duplicate. {% hint style="warning" %} A merge cannot be undone. Check the counts in the dialog before confirming. If you later add the removed application again from **Add New App**, it returns as a normal tracked application rather than a duplicate. {% endhint %} Vendors work the same way, from the [Vendor Directory](/docs/inventory/vendors.md#merge-duplicate-vendors). ## Best Practices * **Triage Shadow IT weekly** so new discoveries do not become an unmanageable backlog. * **Assign a Super Admin** to every approved app so ownership is always clear. * **Assign an Access Reviewer** before starting a campaign so review responsibility is explicit. * **Track renewal dates** to avoid surprise auto-renewals. * **Use the Organization, Team, and Group filters** to divide large inventories into manageable review scopes. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://boza.gitbook.io/docs/inventory/applications.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.