Identity Access is Gigya's tool for managing customer relationships. Use Identity Access to view user account information, edit profile details and perform admin actions. Depending on the features you have enabled in your account, Identity Access shows lite and fully registered users, profile and custom data, loyalty achievements and subscriptions. For example, Identity Access can be used in the following scenarios:
- A service rep provides service to a site user that can't log in, and sends a reset password email.
- A service rep opts a user out from a channel they no longer wish to be subscribed to.
- A marketeer views the segments to which the user belongs, and edits custom information.
- An admin queries all the unverified accounts that have not been updated in over a year, and deletes them.
- A service rep grants Loyalty points to a site user.
List of Users
Open the Identity Access page in Gigya's Console, also accessible from the Console top menu.
The main page of Identity Access shows an unfiltered list of your site or app users.
The table of users includes the users' name, email address, and the day the account was last updated. Under Identities, you can see all the identities the user used to authenticate with, including creating an account on your site, and social networks. If the set of identities includes an ellipsis icon, hover to see all the identities associated with this account.
If a user with an existing full account joins a communication channel while not logged in (creating a new lite account for the user), there will be two references to the user in the IDA overview, one for the full account and one for the lite account. Once the user logs into their full account, and the hasLiteAccount property is updated to true, the duplicate listing will be removed.
Note that this situation will only arise from the time you have the Lite Account license enabled for your account and a user's first login after that point in time, once a user logs in or a new user is registered after Lite Accounts are enabled, the user has a lite account created automatically.
In addition, the table includes the following indicators:
- lite user. :
- : the full registration process was started for this user, but was not successfully completed.
- : fully registered user.
Depending on the admin's permissions, the following actions may be available from the Actions dropdown:
The Verify Email Address and Resend Verification Email options are relevant if your site policies require that newly registered users verify their registration via email, in which case you can resend the email, or bypass the requirement by verifying the email yourself.
Searching for Users
Use the search bar to filter users or search for a specific user. The default is to search by the users' email. To change it, click on Search by and select the criterion.
Note that the search term needs to exactly match the data stored for this user. For example, searching by first name "Alex" will find "Alex Hayes" (assuming "Hayes" is stored as the last name), but not "Alexandra Haze".
When selecting Full Name, the search bar splits into two fields: one for the first name, and one for the last name:
When selecting the Custom criterion, a window opens where you can select up to 10 fields by which to search.
You can select any combination of fields from the special fields, profile, data, preferences and subscriptions namespaces.
Enter a term in the "filter by" to find specific fields quickly.
After selecting the fields, hover over the word "Custom" to see a tooltip with the list of selected fields.
Apply filters to the search results by selecting one of the filters and choosing from the relevant dropdown:
If the filters aren't visible, click the filter buttonnear the search bar.
The available filters are:
- Lite Registration - the user has a lite account, but not a fully registered account.
- Registered: the user has a fully registered account.
- Unregistered: the full registration process was started for this user, but was not successfully completed.
- Verified: the user has verified their email address via an email verification token sent to their email.
- Unverified: the user has not verified their email address. In sites that don't require email verification as part of the site policies, all users will probably be unverified.
Enter an SQL-like expression that will be applied to the query as a 'WHERE' clause. For example - " socialProviders contains 'facebook' and firstName='Amanda' " will display users that match the query, and have a registered Facebook identity, and their first name is 'Amanda'. Note that personally identifying information (PII) fields, such as email and name fields, are encrypted in the database. Therefore, you can't find them using partial strings (e.g. contains 'ama') or relative queries.
Open the full user profile by clicking that user's row in the table, or selecting View User Profile from the main page actions menu.
The user profile shows all the data saved for that user, conveniently divided into tabs.
The left menu contains information that is always available in the full profile view (regardless of tab navigation), such as the user's identities, and UID. In addition, it contains a set of available actions, and the tab navigation menu.
Click the Actions menu to expand it. Depending on your permissions and the specific user, the following actions may be available:
- Verify Email Address: Changes the status of the account to "Verified".
- Resend 'Verification Email': Sends to the user the verification email (defined in the Email Templates section of Gigya's Console) they should have received automatically when registering to your site.
- Send 'Reset Password' Email: Sends to users an email with a token for resetting their password.
- Reset Sharing Settings: For sites that implement Automatic Sharing, resets the user's share settings.
- Remove Identities: Remove a social or federated identity from the user's account. After removal, the user will not be able to log in with that identity, and data from that source will be deleted.
- Reset TFA Devices: Reset the methods of identification used as the second factor for authenticating the user (e.g., phone number, authentication app). In their next login, they will need to register a device.
- Force TFA Expiration: Force the user to provide second-factor authentication the next time they log in.
- Unlock Account: Unlocks a user account that is locked out due to a triggered RBA policy (for example, 3 unsuccessful login attempts).
- Disable / Enable Login: Prevent the user from logging in / Allow the user to log in.
- Delete Account: Permanently delete the user's account.
The Actions menu is not available in the Email Account view.
Full / Email Account Toggle
If you have lite registration enabled on your account, for users that have both full and lite registrations associated with their account, you can toggle between a Full Account view, and an Email Account view.
The Full Account view displays all the information that is available to the user when they are logged in. Email Account is a merged view that contains all the information available in the full account, plus any information that was saved to this email address during lite sessions.
For example, a site visitor subscribes to the 'Pets' mailing list with the email email@example.com, and enters the first name "Vicky", and gives a home address to receive discount coupons. Later, she registers to your site in a full registration process, entering the first name "Victoria", and without providing a home address. In the Full account view in Identity Access, you will see the name "Victoria", you will not see the home address, and you will see the 'Pets' subscriptions. In the Email account view, you will see the name "Victoria" (since it overrode "Vicky", the home address, and the subscription information.
The reason for this division is that full accounts have a higher degree of accountability, and are not updated automatically by "lite" changes to this account.
Information and actions that are associated with the full account, will not be available in the Email Account view.
The Profile tab is the main tab of the user's profile, that displays personal details and custom data saved for this user.
Admins can edit most of the data stored for the user, by clicking the Edit button on the top left corner.
The tab is divided into cards. Depending on your site implementation, the following cards may be available:
- Account Information
- Personal Information
- Custom Information: any custom data (saved in the "data" field namespace)
- Custom SAML Information: when implementing Gigya as SAML IdP, the data served for this user related to their login via a SAML federated identity.
- Custom OIDC Information: when implementing OpenID Connect, the data served for this user related to their login via an OIDC federated identity.
Note that if you have implemented Phone Number Login, this number will appear under the Phone field, whereas other phone numbers will appear under Additional Phones.
If your schema includes complex fields (i.e. fields that are more than one hierarchy deep, such as data.children.name), or fields that store an array of values, these will be displayed in a separate widget, structured to allow handling this data:
Click on the right arrow to delve deeper into the hierarchical structure of the fields:
- To delete an item, hover over a row to display the X icon, and select it.
- To edit a value, click it and start typing.
- To add an item (to add a value to a previously unpopulated field), select the field from the dropdown, type the value, and click "+":
If you have implemented Communication Preferences, the Preferences tab displays subscription information for this user.
It is important to note that the IDA Preferences menu item only appears in the Gigya console if the applicable schema has at least one active subscription or one active consent configured for the site (the specific user does not need to have an active consent or subscription).
The tab displays a list of subscriptions recorded for this user, and their status.
- Expand a subscription to see more information, such as tags, and for subscriptions that require double opt-in, and the time the confirmation email was sent. You can also add a tag in this view.
- Subscriptions that do not require double opt-in, will display a status of "Opted In". Subscriptions that do require double opt-in, may display also a "Pending" status.
- Subscriptions from which the user opted out, are not displayed.
If the subscription is assigned a description, it will be displayed as the subscription name. If not, the subscription ID is shown instead.
- You can opt the user out of a subscription (unsubscribe them). After doing so, this subscription will disappear from the list of communication channels.
- For subscriptions that require double opt-in and have a "Pending" status, you can resend a confirmation email.
If your site package includes Customer Consent, you will have access to the Privacy Tab, which displays the user's consent status to your site's terms of service, privacy policies and other consent statements.
It is important to note that the IDA Privacy menu item only appears in the Gigya console if the applicable schema has at least one active consent or one active subscription configured for the site (the specific user does not need to have an active consent or subscription).
If your site includes many consent statements, you can search by the consent ID, and/or filter by the date the user gave their consent.
In addition, site admins can:
- View the legal statement that was in place when the user gave their consent
Revoke consent on the user's behalf. This option is available only for non-mandatory consent statements.
All active terms of service and privacy policies are mandatory, and the only type of statement which may be non-mandatory is the "other" statement.
- Date Range: select the start and end dates of the period to display:
- Consent Type
- Additional Details: Filter by any tags associated with this consent statement.
- Consent ID
Click on any timeline event to expand it and view its details, such as the consent statement version, the document and purpose to which the user agreed, and the IP address of the user who performed the action.
Clicking on the API key, the call ID or the IP address copies them to the clipboard.
Depending on the specific consent interaction, the following fields may be displayed, and may or may not contain data:
|Version||The consent statement version that was active at the time the action was performed.|
|User/Application||If the update was made via a User or Application key, the ID of the key.|
|Additional Details||Any tags that were appended to this consent interaction.|
|Purpose||The purpose defined for this consent statement that the user agreed to.|
|Entitlements||If the user has granted consent to any entitlements during this consent interaction, a list of those entitlements.|
|Action||The action that was performed.|
|Country||The country from which the call was made.|
|Login IDs||The Login ID(s) of the user.|
|Performed By||How the update was made, whether a Console User, Client (via Gigya WebSDK), or Application.|
|Language||The language of the Consent Template that the user consented to.|
|View Legal Statement||Clicking will open the URL of the legal statement that was in place when the action was performed.|
|Action Timestamp||The time at which the action was performed.|
|API Key||The API key of the site for which the consent interaction applies.|
|Call ID||The unique call ID, which can be used for further investigation in the Audit Log.|
|IP||The IP address that the API call originated from; this may be the client-browser or the server that made the API call.|
|Custom Data||If any custom data was defined for this consent statement, this will be displayed as key-value pairs.|
You can see an audit of the user's journey through your site in the Audit Log tab of Identity Access. The tab shows any audited changes that affect the user's account, whether made by the user or an admin.
The Account Audit Log is a sub-set of the general site Audit Log, so only APIs that are tracked there are available within the Account Audit Log.
Audited APIs include the following:
- accounts.setAccountInfo (changes to data, profile, subscriptions, and/or preferences objects or when a password is changed/updated)
- All other audited APIs that return a UID, fall under the category "Audited Event".
The retention period for the audited events is defined in the Settings page of the Admin tab in Gigya's console. The possible values are 6, 12, 18 or 24 months. Each event is saved for the length of time that was in place when it was audited.
Use the available filters to search for a specific event on the user's audit timeline:
- Date Range: Select the start and end dates and hit "Apply".
- Filter By specific actions on the account. You can multi-select the actions by which to filter:
Getting Additional Data
If you need detailed information about the event you can copy the Call ID from the event details pane and use it within a full Audit Log query to get the event's complete details.
Occasionally an API call may fail for whatever reason. In cases where this happens, you will see a record of the event in red, and a description of the error that occured.
Click on the event for additional information.
If Loyalty is enabled on your site, you can see the user's achievements in the Loyalty tab.
Displays the user's achievements, including the number of redeemable points out of the total points, and perform the following actions:
- Grant points
- Revoke points
- Redeem points
View the log of actions that occurred during a specified date range: