Access Statuses

Overview

Blissfully allows you to easily model the intended relationships between the members of a team and the applications they should have access to. This simple, yet powerful concept opens an entirely new window into the state of user-access across your entire enterprise. Blissfully unlocks the ability for an Administrator to clearly identify who should (and should not!) have access to an application, and easily close the gap between your intent and a reality that often includes unexpected access or frequent exceptions.

Team/App relationships

After setting up your teams, you can start adding applications that you intend for team members to have access to. When adding an app to a team, it can be marked as required or set as optional for all members. Once added, Blissfully considers the app to be "authorized" for use by all team members. Whether the app is designated as optional or required will have an impact on the status of a user's relationship to an app, as described in detail below.
App status
Suggested usage
Required
Best when access is expected of all team members, as part of employee onboarding
Optional
Best when access is granted only by request, outside of required onboarding actions
Apps can be set as required or optional for all members of the team

Person/App access statuses

If a person is a member of a team that is authorized to use an app they automatically have a relationship with that app, and one of four unique provisioning statuses. Frequently, these statuses are detected and driven through one of our many integration sources (Google Workspace, O365, SSO, or direct license) but all of them can be manually asserted by an Administrator.
Status
Description
Has Access
Blissfully has detected access to the application through an integration or an Administrator has manually asserted that the user has access
Need Access
The user is expected to have access based on their team but no access has been detected, and an Administrator has not confirmed that they have access
Optional Access
The user is allowed to request access based on their team but no access has been detected, and an Administrator has not confirmed that they have access
Access Revoked
The user had access at one point but the access was either manually removed or the user's status was detected through an integration.
The provisioning status lifecycle is typically as follows: A user who is a member of a team authorized to use an application starts out with a "Needs Access" or "Optional Access" status depending on the settings of the team in question. Access is automatically detected through an integration, such as Google, or manually granted by an Administrator through a Grant Access or Onboarding workflow, and the user is given the "Has Access" status. Once a user has access, an "Access Revoked" status can be manually asserted by an Administrator or detected through an integration source. Users marked as revoked can also have their access reconfirmed.

"Unexpected" access flags

One of the primary benefits of Blissfully's team-based status model is to help reveal the scourge known as Shadow IT. In this context, Shadow IT can best be articulated as a user having unexpected access to an application based on IT's intent. An "Unexpected" flag will appear on a user who "Has Access" when they are not a member of a team authorized to use the app in question. These flags can be easily cleared by an Administrator either by adding the user to an authorized team or granting an access exception.
Flag
Meaning
Unexpected
Access has been detected but the user is not a member of an authorized team
Access Exception
Access was granted despite the user not being a member of an authorized team

Example walkthrough

Anthony is not a member of a team authorized to use FullStory but has access to the app. Access was detected automatically through Blissfully's integration with Google Workspace, as seen in the SOURCES column. Anthony has no data in the AUTHORIZED TEAM column, confirming that this is indeed unexpected.
As a concerned Administrator, I independently verify that Anthony is supposed to have access to this application with his boss. His boss confirms that Anthony is intended to have access and is actually a member of the Product team, which has designated FullStory as a required application. As such, I decide to override the flag through the action menu.
The override action allows me to directly add Anthony to the Product team without needing to leave the page. I can search for any team that is authorized to use FullStory.
After I confirm the dialog, a success message appears in the bottom corner of the screen, and the table row is refreshed. Anthony is now a proper member of the Product team, and the Unexpected flag has been removed from view.
I find another user with an "Unexpected" flag, this time on Miro. Aaron is the CTO of the organization, and is not officially a member of any team that has authorized its use but I recognize that he should be allowed to have access.
Before taking any action, I check with Aaron to make certain he really wants to maintain his access. He confirms that he would like to continue using the app, it's valuable and he uses it frequently. As such, I jump into the action menu again, but this team manually affirming his access without adding him to a team.
After I confirm the dialog, a success message appears in the bottom corner of the screen, and the table row is refreshed. Aaron's Unexpected flag has been removed and replaced with an Access exception flag. This lets me know that even though Aaron is not a member of an authorized team, he is still intended to have access to the app. These actions are also reflected in the source data and audit logs.

Settings

Team-based access statuses are turned off by default when first onboarding into Blissfully in order to give new customers the chance to properly set up their teams first. To take advantage of these powerful capabilities, navigate to the General Setting page to toggle the feature on or off.
Last modified 3mo ago