Apps

Your app inventory: every tool employees use, with ownership, lifecycle, cost, and security attributes. Route requests by app, pick approvers automatically, and trigger provisioning in your IdP

Applications are your app inventory: every tool employees use, along with ownership, lifecycle, costs, and security attributes.

Why it matters

• Clear ownership: know who approves access and who to notify during incidents.

• Better workflows: route requests by app, pick approvers automatically, and trigger provisioning in tools like Okta/Azure AD/Google Workspace.

• Visibility: analyze usage, categories, and costs.

Manage application fields Customize the fields that describe apps (and their visibility). Common fields include:

• Owner, Teams, Category, Lifecycle (e.g., Active, Security review)

• Sensitive data (Y/N), Status page URL

• Contract details (renewal date, vendor, currency)

• Annual cost, Licenses, Jurisdiction, Hosting Turn fields on/off and set the structure that fits your governance.

Inventory and profiles

• List: search and filter apps by category, owner, lifecycle, or cost.

• Profile: see the app’s details, owners, related teams, and linked requests. From here, open the status page or start/approve access workflows.

Owner and Backup owner

You can assign an Owner and a Backup owner to each app. Either one can be a person, a team, or an inbox.

When the owner is a team or an inbox, every member counts as an owner of the app. Any member can decide an approval that targets that owner, and the first decision settles it for the whole group. Other approvers in the policy still need to decide. Manual app owner tasks are assigned to all of the group's members.

Owner and Backup owner are separate approvers. An approval step that targets App owner goes only to the Owner, and one that targets App owner backup goes only to the Backup owner.

Active Users

Every app profile has an Active Users tab: a live, reconciled view of everyone who currently has access, pulled together from every source Siit knows about.

• Always up to date : a grant or revocation through your IdP or through App Access updates the list immediately. Siit reference-counts access, so someone stays listed as long as any source still grants it, and drops off only once the last one is gone.

• Origin at a glance : each person shows how they got access: an IdP provider, App Access, or a direct admin add. Access can come from more than one source at once.

• Usage as a source : with Microsoft Entra ID connected, signing in to an app through SSO makes someone a user of that app in Siit, with or without an assignment. Usage based memberships expire when the person stops signing in, so the list stays aligned with real usage.

• Full activity history : an activity timeline follows every event behind the current state: request creation, approvals, manual and automatic actions, provisioning failures, cancellations, and planned deprovisioning.

Merging applications

When the same tool appears twice in your inventory, for example one record created by hand and another imported from your IdP, you can merge them into a single application.

Open the application you want to keep, open its action menu and choose Merge application. Select the duplicate to merge into it and confirm with Merge. The application you opened is the target and stays. The selected application is removed.

What the merge keeps and combines:

• Target information wins. Fields on the target keep their values. Fields the target leaves empty are filled from the merged application. If the merged application was approved, the target becomes approved.

• Active users are combined. Everyone with access to the merged application gets access to the target. People who already had access to the target keep their existing record.

• App instances are combined. Instances discovered by your integrations on both applications now belong to the target.

• Roles and access requests move over. App access roles, including archived ones, and their pending or past access requests move to the target. A role with the same name as one on the target is renamed with a "(2)" suffix.

• Requests, favorites and documents follow. Linked requests, favorites and attached documents point to the target.

• Workflows and campaigns stay valid. Workflow triggers, branches and actions that referenced the merged application now reference the target, as do communication campaigns. Older request history and form answers are updated in the background a few moments later.

• The activity timeline records it. An "Application merged" event appears on the target's activity, with the name of the merged application.

Merging can't be undone. The merged application is permanently deleted, not archived. Review both records before you confirm.