The bundled Appian Usage Insights Installation Guide describes how to do this.
The bundled Upgrade Notes document describes how to do this.
The bundled Appian Usage Insights Quick Start Guide describes how to do this.
Users are identified by distinct username. Their group membership and logins are considered across all environments based on the same username. For example, john.smith in Environment A is considered to be the same user as john.smith in Environment B, but not the same as john.smith@acme.com in Environment C.
You can modify the configuration (business entities, license pools and groups, license types etc) and rerun analysis on the latest collection run as many times as you need to get the configuration right. You can only run analysis on the latest collection run, so once you load the next collection run (a few weeks later) then any further configuration changes will only apply to analysis of that next collection run data.
After each new collection run you need to run analysis again on that latest collection run. The majority of the reports are based on the analysis of the latest collection run (except for the capacity planning report and user logins over time), so will not display any data until analysis has been run on the new collection.
From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. If the constants LMA_R_APPIAN_USAGE_INSIGHTS_COLLECTOR_VERSION or LMA_R_APPIAN_USAGE_INSIGHTS_REPORTING_VERSION do not exist in your app, you are either running v1.0.0 or v1.0.1. In this case, if your reporting database includes the Stored Procedure LMA_SP_USERS_BY_license_TYPE, then you are running v1.0.1.
From v1.1.0 onwards the Appian Usage Insights Quick Start Guide describes how to do this.
From v1.1.0 onwards you can do this via the related action within any license type record. See the Appian Usage Insights Quick Start Guide for more information.
Business entities are a fairly flexible concept that allow you to model usage in the most appropriate way for your business. A standard approach - that provides an overview at business unit level while allowing visibility on a per-app level too - would be to configure business entities for your organisation's larger business units, and then model the apps that belong to those business units as entity license pools. For this you would create one or more license types per app.
For example, you might configure "Finance" as a business unit, create "Fin App1 Enterprise Users", "Fin App2 Enterprise Users" and "Fin App3 Enterprise Users" as license types, and map those to the Finance business entity by creating an entity license pool for each license type within the Finance business entity. For each of those entity license pools, you would configure the groups that allow you to identify users of each of those apps (so the entity license pool for "Fin App1 Enterprise Users" might be the group "Fin App1 All Users", for instance).
When you find users that still end up in the Default entity, it's because you haven't mapped a group for them in your Business Entity - license Pool structure. The aim is to end up with no one left in the Default pool, so you know you have configured things correctly. This can take several iterations.
Usage analysis and the resulting reports are based on a snapshot of usage across all in scope environments at the same time. Therefore, for each new collection run loaded into the reporting application, a collection for every active environment is required. These collections should generally have all been run on the same day, or close enough.
From v1.1.0 it is possible to deactivate an environment so that no further collections need to be uploaded for it. This would be used where an environment that was being reported on is no longer being used.
You should consider whether your organisation allows the data that the collector application collects to be stored in a non-production environment. Additionally, as you use the application and the data stored in the reporting application grows, you should consider how you manage capacity in your chosen non-production environment.
As with any App Market app, clients are responsible for testing these apps in their own environments. When rolling out the Appian Usage Insights applications within your organisation, ensure that the apps are tested in your non-prod environments first according to your usual testing and release procedures.
Currently (v1.1.0) the only export functionality included is the high level Usage by Business Entity report, which can be exported via the "Download usage by business entity" download link on the Usage Reports > Usage By Business Entity report.
Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.
The data collection component will collect a maximum of the last 30 days worth of login information. If you have run the collector in the last 30 days, it will collect the login information since the last time it ran. Over time as the collector is run (at least every 30 days) and the collections are loaded into the reporting component, you will build up login data across a longer period. The application doesn't support collecting older, compressed login audit data. This doesn't prevent the allocation of users to license pools (which is based on the most recent group membership collections). But it does mean that the login information displayed in the app will only become more meaningful as collections are built up over time.