Under Applications - select your preferred application and navigate to users; select the Add Filters button “ license mapped “ as false.

Go to users and click on “ external users “, and then you’ll see the list of all external users.

To bulk import, the user data, go to users, choose the three dots, and select “ Bulk update data “. Download the editable CSV file and then upload the modified CSV.

To check the primary source of a user application, Kindly choose the user and then select the" applications'' post, where you'll be able to see all the applications and their sources.

To mark a user inactive on Zluri, kindly go to users, select the user and click on change status, as shown in the below screenshot.

You can also click on the three dots next to the user and mark it inactive, as shown in the image below.

To view the total number of inactive users, Go to users and choose the filter “ status “ is any of inactive “ to view the inactive users.

To find if a user has an alternate email address, Go to users and select the user you want to find the email ID for. Once selected, scroll down to find “ Email aliases “ and select view all, and you’ll be able to see all the email ids for this user.

In specific applications such as Okta and Google workspace, there are options to create a group account. Let us assume that a user, abccustomerservice@Zluri.com, is created. In that case, it is automatically gathered into employee data. But if specific steps are taken to create this account as a group on the SSO, then the employee data is populated under the Group section respectively.

A user can be marked as a “Service” account on Zluri by navigating to Users -> Select users who need to be marked as Service accounts -> Bulk Edit -> “Change User Type” -> “Service”.

Two types of data points related to usage are shown in Zluri's UI.

• "Last Used" information is shown under Application -> Users 

• "Activity" information is shown for each application user

1. "Activity" comes from multiple sources (SSOs, direct integrations, agents), which provide information about some or all actions performed by that user specific to that Application, each with an activity-specific timestamp. 
   
   Activities can be a few different things - logins (either from SSO or direct integration or agent) or specific actions taken on the platform, which some SSOs give us and some integrations give us (opened this page, ran this export, etc.) but not all. Each activity comes with a timestamp with which we plot all activities over time and have a log of the most recent activity.
   
   Zluri shows a log of all activities specific to that Application that comes from all of these sources - 

   1. Most SSOs only provide login activities.

   2. A few direct integrations provide more in-depth activities (viewed a page, downloaded a report, changed a setting, etc.).

   3. Agents provide activity info on the Application being used. 
      
      

2. "Last Used" info is provided directly by some integrations which tell us exactly what the last login or last used date is
   
   Zluri shows the last used date for that application user based on the most recent date we receive from either activity (from point 1) or the last used date from the integration. If we get neither, we indicate that we do not have a last used date for this app user (denoted by a hyphen "-" in the column)
   
   Some integrations give us the Last Used field by itself, but most don’t. We show either this as is or the most recent activity we got, whichever is the most recent date.
   
   

How we validate "last used" data 

Step 1

We compare two data points -

• 'Raw_last_used' (Data from the direct integration)

• 'Db_last_used' (data from all the sources combined: Direct/indirect integration + browsers/desktop agents

Using these two data points, we do an internal validation: 

• db_last_used >= raw_last_used: Validated 

  • This means we're showing the last used date we get from the integration or the most recent activity, whichever is the most recent.

• db_last_used is there, but no raw_last_used: Validated 

  • This means that we're not getting the last used date from the integration, but we have activity data from other sources

• raw_last_used is there, but no db_last_used: Not validated

  • This means that we're getting the last used date from the integration, but we're not processing it accurately

• raw_last_used > db_last_used: Not validated

  • This means we're getting a last-used date from the integration, which is not processed accurately; instead, we're displaying stale data.

• both fields are empty: Validated

  • This means that we're not getting any data from activities from all sources or the last used date from the integration, and we're displaying it as it is.

Step 2

Next, we compare raw_last_used with Client shared data: 

• If raw_last_used >= (date shared by the Client): Validated 

• If raw_last_used < (date shared by the Client): Not validated

Step 3

If the data is validated from both step 1 and step 2, then we confirm that the last used date shown on the UI is validated, else it is incorrect. 

Note: In case we do not get any activity data from a customer for an application's users, we will need to do only the internal validation mentioned in Step 1

Caveats:

Zluri date > Client shared date: 

This can happen when the Client shares the last used date from one source (or they see a different date in their Application); however, we get the last used information from multiple sources. 

For applications where we get the data from multiple sources, the last used date shown in the UI is the most recent of all dates we get from different sources.

We store the activity type that we are getting for that Application. If we don't detect any activity type in the activity file, it is taken as a sign-in activity by default.

To accomplish this, we check the activity data and utilize the last used filter.
Choose the relevant date and filter it from the source selected as the secondary source.

We can assume that the users are not using the application if no activity is detected.

Until and unless we don't get a token/activity that says that the user is not using this app anymore, it's marked as active. It can occur through SSO when the user departs from the organisation, and their data is deleted. The login/auth tokens expire for the specific application.

Additionally, we can mark the user app status as inactive when offboarding them through workflows to an application that is not directly integrated.

What is the threshold for this? For example, do we mark users as not in use if we don't get token activity for 30/60/90 days?

For Okta and Azure, every user added to an application gives this status automatically for apps. So, it's basically the direct source for user-app status.

For Google WorkSpace - It was seven days. If we don't get a token, we need to verify this.

For Agents, it was seven days. We used to mark user app status inactive if data is not received for more than 7 days. 

Let's say we are merging User A to User B[User A--->> User B], the data from User B will be the one that will remain with its attributes and values. User A's attribute values will not override the ones that are in User B.