An Experience User is a unique user registered to your application’s Experience. Users can access protected Endpoints and can be associated with Devices via their membership in one or more Experience Groups. You can also build full metadata profiles for each user.
Viewing Experience Users
Click the “Users & Groups” link under the “Experience” section of your application’s menu. From here, you can view lists of all experience users, as well as all users who are assigned to any experience group or are not assigned to any group.
Click the user’s email address in the list to view and to edit their profile.
Adding an Experience User
From the “Users & Groups” section, click “Add User” in the left column. If you are viewing one of the lists of experience users, you may also click “Add Experience User” at the top right of the page. These actions will take you to a page where the new user can be configured.
There are a number of fields that can be set for a user, some of which are required.
- Email Address: This must be a valid email address, and it must unique across your application. It is possible to register experience users with the same email address across multiple applications, but each user will count against your resource limits.
- Password: A user’s password must be at least 8 characters long. When creating a user, this field must be set; when updating a user, it is not necessary to assign the user a new password unless you have checked the “Change password?” box.
The combination of these two values is what your experience users will use to authenticate against your application.
- First Name and Last Name: The user’s first and last names. These can be any string, or they can be left blank. You may also set one but not the other.
- Groups: Any Experience Groups the user should be a member of. Assigning a user to a group will associate that user with any devices that are tied to that group or any of its parent groups.
Tags allow for the storing of arbitrary data against any Experience User. Tags are useful for:
- Storing additional profile information, such as phone number or street address
- Mapping experience users to other services, such as Facebook or Twitter, by storing their third-party IDs
- Querying experience users in a workflow using the Get Experience User Node.
A tag’s key may only include uppercase and lowercase letters; numbers; and hyphens (-) and underscores (_). A tag’s value can be any arbitrary string. A key may only be set once per user; you may not, for example, store the variable
phoneNumber as two separate values for one user.
Any tag keys that have been used with other experience users will be available as “autosuggest” options when you enter new keys.
Invalidating User Tokens
Sometimes, it may be necessary to invalidate access tokens for one or more of your experience users - particularly if you have reason to believe users’ credentials have been compromised. This action does not edit or delete any of your experience users; rather, it simply requires that they all log in again before making any authenticated requests.
At the top of the “All Users” list is a button to invalidate the tokens of all experience users. This will display a confirmation modal, and immediately after clicking the modal button, any authenticated request made by an experience user will fail until that user has logged in again.
At the bottom of an individual user’s edit page is a box for invalidating any access tokens issued for that one user.
Invalidating a user’s tokens simply means that the user must re-authenticate using their email and password before they can make any more requests to authenticated Endpoints. It does not take any destructive action on the user, nor does it automatically change their password.
An experience user can be deleted by clicking the “Delete” option in the dropdown in the user’s list row. Or, as with other resources, you may also click the “Delete” button in the footer of a user’s edit page.
Deleting a user will automatically remove them from any of their Experience Groups, and if the user requests any protected Endpoints after being deleted, their request will fail.