Managing User Profiles

User profiles are the personal information stored for a user. In some cases, this information was collected directly from the user; for example, during registration the user might have filled out at least part of their user profile. In other cases, the information might have been collected via social login: when a user logs on with, say, a Facebook account or a Twitter account, the user can give permission for information from that account to be copied to their Janrain user profile. (What information? That depends both on the account used for social login and on how social login has been configured for your web site.)

Of course, there’s more to managing user profiles than simply collecting profile information. For example, administrators can also perform such tasks as:

Each of these tasks are detailed in this section of the Console documentation.

Viewing Profiles on the Manage Profiles Page

In the Janrain Console, user profiles are viewed, and managed, from the Manage Profiles page:

The Manage Profiles Page

By default, the Manage Profiles page serves as your home page each time you log on to the Console; in addition, a Manage Profiles link appears in the Console navigation pane. Note, however, that the “link” shown in the Console (Manage Profiles) isn’t actually a link; instead, it’s an expanding/collapsing list. If you click Manage Profiles you won’t go anywhere; you’ll just show or hide your entity types (i.e., your database schemas):

The Manage Profiles Link

Instead of clicking Manage Profiles, click the entity type itself (e.g., user); that takes you to the appropriate page. That’s not a particularly difficult feat to master, it’s just something you’ll need to get used to.

After you do get to the Manage Profiles page you’ll be able to carry out such tasks as searching for user profiles, creating profiles, exporting profile information, or viewing the details of an individual profile. For example, to do the latter, simply click the record of interest in your list of profiles.

The Janrain Console also gives you a limited ability to control the look and feel of the Manage Profiles page. For example, you can sort the data by any indexed attribute; you aren’t limited to the default sort order. (By default, users are sorted by account creation date, with the most recently-created profile shown first.) If you aren’t sure which attributes are indexed (i.e., which attributes are sortable), hover your mouse over the column headers. If the underlying attribute is searchable (and sortable) you’ll see an upward-pointing arrow:

Sorting User Profiles

Click the arrow to sort the data by the corresponding attribute, and in ascending (A to Z) order:

User Profiles Sorted by Email Address

And then click the arrow a second time to sort the data in descending order (Z to A).

You can also choose which attributes are displayed in your search results. For example, suppose you want to show user address information (e.g., city, state, and country). You can do that:

Displaying User Location Information

Alternatively, you might want to show user account information (e.g., account creation date, last login time, account deactivation status). You can do that, too:

Displaying User Account Information

It’s entirely up to you.

In addition to all that, the Console also allows you to manage the amount of information displayed at any one time. Records are “paged” in the Console: instead of listing all your records at the same time, only a subset of records are displayed. (To view additional records, use the page controls in the lower right corner of the Console.) By default, the Console displays 10 records at a time; however, by clicking Rows per page you can choose to display 25, 50, or even 100 records at a time:

Selecting the Number of Rows Displayed on a Page

Most important, the Console also enables you to perform a number of important management tasks, including:

What Happens to Your Search Results When You Leave the Manage Profiles Page?

As a general rule, your search results (and the sort order assigned to those search results) are not permanent. For example, suppose you run a search that returns 5 user profiles, and you sort those 5 profiles by the user’s last name. Suppose you leave the Manage Profiles page (e.g., to go to the Manage Agents page) and then return. When you return, you’ll no longer see those 5 user profiles sorted by last name. Instead, you’ll see the results of the default search query (which returns all of your user profiles, sorted by creation date). That’s just the way the system works: search results disappear if you leave the Manage Profiles page.

Or at least that’s the way the system usually works: as it turns out, there is an exception or two to that general rule. For example, suppose you run a search that returns the following 3 user profiles:

Sample Search Results

If you go to a different page (for example, the Manage Agents page) and then click the Manage Profiles link, you’ll see that your search results have disappeared: clicking Manage Profiles effectively resets the search results. However, if you use your browser’s Back button to return to the search page, then your search results will be exactly as you left them:

Using Your Browser's Back Button

In other words, you can use the Back button to return to the Manage Profiles page without overwriting your existing search results. Likewise, suppose you click on one of the profiles in those search results. In the profiles editor, note the Search Results “bread crumbs” at the top of the page:

The Search Result Breadcrumbs

Clicking Search Results also returns you to the search page without changing the search results or the sort order:

Search Results Not Deleted

Creating a User Profile

Typically users register on a web site either by employing traditional registration (i.e., registering with an email address and password) or by using social login (that is, by using an account from a supported identity provider such as Instagram or LinkedIn). Regardless of the registration method, however, each time a user registers with a web site a Janrain user profile is automatically created for the new registrant. And users typically create their own user profiles.

However, that doesn’t have to be the case: the Janrain Console enables administrators to create new user profiles by prepopulating attributes such as email address, display name, address, and phone number. After the profile has been created, an email is sent to the new user; he or she only needs to click a link in that email and create a password in order to log on using the pre-created account.

Note. Currently there is no way to import a spreadsheet or a text file containing user information and then create a new account for each user. Instead, new accounts must be created individually. However, you can call the entity.bulkCreate API to create multiple accounts in a single operation.

If you want to create a user profile for someone, you can do so by completing the following procedure:

  1. From the Manage Profiles page, click Create Profile:

    The Create Profile Button
  2. From the Create Profile page, verify that the correct API client is selected in the Property field. If you only use one API client for logins then you don’t need to worry about this: that one client will automatically be selected.

  3. After you verify the API client, enter values for all the required fields (indicated by an asterisk following the fields name). By default, the following user profile fields are required:

    • Property
    • First Name
    • Last Name
    • Email Address
    • Display Name

    At this time you can also can enter values for optional fields.

  4. Click the Create Profile button:

    Saving a User Profile

After you click Create Profile, the account is created and the new user appears in your list of user profiles. In addition, the user is sent a registration verification email. (Although organizations can choose to bypass email verification.) The user must click the link in the email to access the Email Verified page and then create a password for their account. After the password has been created, the user will be able to log on to the web site.

See Also

Working with the Property Attribute

In order to log on to a web site, user accounts must be associated with an API client that has been assigned the login_client feature set. That explains why only API clients that meet that criteria are available when you create a user profile through the Customer Care Portal. For example, suppose you have the following set of API clients, two of which have the login_client feature set:

API Clients

When you create (or modify) a user profile in the Customer Care Portal, only the two login-client API clients appear in the Property dropdown list:

Selecting an API Client

Note. Yes, in the Customer Care Portal the login client field is labeled Property. However, if you look in the schema, you won’t find an attribute named Property. Instead, the Customer Care Portal’s Property setting maps to the clients.clientID attribute. The schema also displays the login client by client ID (e.g., c5ukftq8n6fene4mgw6bvbhb5vj87rps) rather than by client name (e.g., EMEA Login Client).

When you create a new user profile, a login client is automatically selected for you, and there’s no way to avoid that: although you can change the default selection (assuming you have more than one login client), you can’t leave the Property field blank. You must specify a login client in order to create and save a user profile using the Customer Care Portal.


In case you’re wondering, if you only have a single login client then that client will automatically be selected and assigned to the user when creating a new user profile. But suppose you have more than one client (for example, clients A, B, and C). By default, the Customer Care Portal automatically assigns the first client in the list (Client A) when new profiles are created. However, suppose you create a new profile and change the user’s Property to Client B. The next time you create a profile Client B, the last login client assigned to a user, will be selected and assigned to the user.

And yet, it’s still possible to run into a user who doesn’t have a valid login client. (How could that happen? Well, to name one instance, the login client originally assigned to the user might have been deleted.) If a user doesn’t have a valid login client, you won’t be able to access the user’s profile in the Customer Care Portal until you assign the user a valid login client:

Specifying an API Client

If you end up in this situation, you can assign the user a login client by clicking the Property arrow and then choosing from the list of available clients:

Specifying an API Client

After that’s done, you’ll be able to access the user profile without any problem.

Note. Does it matter which login client you assign to a user? It might: after all, API clients are often configured differently from another. In fact, you typically won’t have multiple API clients unless you need multiple API clients. That suggests that yes, it can matter which API client you assign to a user.

The Property attribute also plays a role any time you send emails (such as password reset or email address verification emails) from within the Customer Care Portal. For example, suppose you have two login clients: the default login client, and a second login client named EMEA Login Client. Let’s further suppose that you need to send an email address verification message to a user (a user associated with the default client). If you access the user’s profile and click Resend Verification, the email will reference the default client site (Documentation Test Site) in the message:

The Default Registration Email

However, suppose you change the user’s Property attribute to EMEA Login Client. In that case, the message references the EMEA Login site instead:

Alternate Client Registration Email

The moral of that story? If your API clients use different email verification and password recovery URLs, changing the Property attribute helps ensure that activities such as these take place at a specific web site.

Managing the Full User Record

By default, the Janrain user schema (which specifies the data that can be stored in a user profile) contains over 250 attributes: without making a single customization to the schema you can find a place to store a user’s name and email address, a place to store the name of the user’s hero, a place to store information about books the user has read and movies they’ve seen, even a place to store the user’s blood type or what the user is afraid of. This doesn’t mean that you need to use all these attributes, or that you’d even want to use all these attributes. It just means that the user schema is very large, and very comprehensive.

As a general rule, sites typically directly expose users to only a handful of these attributes; for example, a user profile might contain a select list of attributes such as:

  • First Name
  • Middle Name
  • Last Name
  • Gender
  • Birthdate
  • Display Name
  • Email Address
  • Phone No.
  • Street Address
  • City
  • State
  • Postal Code
  • Country
  • Mobile Phone No.

However, the attributes you expose to users is entirely under your control. In addition, your organization might make use of other attributes without requiring users to enter this information. For example, information about favorite books or movies might be copied over from another web site as part of social login. Regardless, the user profile is built to accept all of this information, no matter how it might be obtained.

In the Janrain Dashboard, administrators always had access to a user’s complete record, including all those lesser-known attributes such as profiles.profile.scaredOf. This information was traditionally found on the Capture Dashboard’s Records page:

The Capture Dashboard Records Page

In the initial release of the Janrain Console, the complete user record was not available to administrators; instead, admins were limited to viewing the same handful of attributes that were exposed to the user. Fortunately, this is no longer the case: the most-recent version of the Console includes “full record” viewing and editing of user data.

To access the full user record for a user, simply click the appropriate user account from the Manage Profiles page. By default, that opens the Edit User Profile page, a page that shows the limited set of attributes that are exposed to users:

The Edit User Profile Page

However, you can access all the attributes for the profile by clicking Edit Full Record:

The Edit Full Record Links

Generally speaking, the full user record is easy to work with. With the exception of a handful of read-only attributes (such as created), you not only can view all the attributes for a user account, but you can modify those attributes as well. For example, suppose you have a user named Bob, a user who would prefer to go by Robert:

Changing a User Attribute Value

To accommodate this user, simply double-click the givenName field, change Bob to Robert, and then click the Save Changes button. The change takes effect immediately:

An Updated User Attribute

In fact, there are only a couple of things to watch out for when working with the full user record:

Plurals and Objects. Plurals (and objects) are attributes that can contain multiple values; these might be multiple iterations of the same thing (for example, any number of books that a user has read), or they might represent a collective group of information (for example, the primaryAddress object contains such individual values as streetAddress, city, country, and stateAbbreviation, all of them related to a user’s physical location). Plurals and objects can be readily identified in the full record; they’re designed to look like a stack of information (which, of course, is exactly what they are):

Full Record Plurals Example

To “expand the stack” and to look at all the underlying attributes, just click anywhere on the plural/object. For example, here’s what you see when you expand clients:

The Expanded Clients Attribute

And this is what you’ll see when you expand primaryAddress:

The Expanded primaryAddress Attribute

Like we said: easy.

Times are calculated by using Coordinated Universal Time (UTC). Full record editing includes date pickers and time pickers that make it easy to enter dates and times (and to ensure that those dates and times are correctly formatted). For example, to enter a date (such as a user’s birthday) you can use a date picker similar to this:

Full Record Date Picker

And to enter a time (such as the time of day when a user account was deactivated), you use a time picker similar to this:

Full Record Time Picker

The only thing to keep in mind is that times are always displayed – and are always stored – by using UTC time rather than local time. For example, suppose it’s 2:21 PM Pacific Standard Time in Portland, OR. By default, however, the time picker will show the time as 10:21 PM; that’s because UTC time is 8 hours ahead of Pacific Standard Time:

Full Record UTC Times

That’s just something to keep in mind.

Speaking of times, the time picker shows the correct time (e.g., 10:21 PM UTC), but, at first glance, seems to only allows you to change the hour of the day, something you do by clicking a different hour:

Changing the Hour of the Day

But don’t fret: you can change the minutes as well as the hour. To do that, click the minutes in the displayed time, then click to change the minutes accordingly:

Changing the Minutes of the Day

You can also toggle between morning and evening by clicking AM and PM:

Changing from AM to PM and Back

And that’s really all you need to know in order to start using the full user record.

Resending Verification Emails

Verification emails are automatically sent when you create a new user profile or when a user first registers with a web site. (Unless, of course, you disabled these verifications.) But what if the verification email never arrives, or what if the user inadvertently deletes it? How much trouble is that going to cause?

To be honest, that’s not going to cause any trouble at all. That’s because you can resend a verification email at any time by completing this two-step procedure:

  1. From the Manage Profiles page, click the appropriate user profile.
  2. From the Edit User Profile page, click Resend Verification.

After receiving the email the user simply clicks the enclosed link to verify their email address.

By default, users can log on to a web site even if they have not verified their email address. However, organizations have the option of configuring their site to prevent logons from users who have not verified their email address.

Tip. If you have indexed the emailVerified attribute you can search for users whose have not verified their email address. If there’s no value in a user’s emailVerified attribute that means that the corresponding email address has not been verified.

See Also

Resetting a User Password

No one (including Administrators) has access to user passwords: nobody can read a user’s password nor can anyone set or reset a user’s password. So what do you do if a user contacts you because he or she has forgotten their password and can’t log on to the site? One thing you can do is click Send Password to send the user a link to a page where they can create a new password.

To help a user reset their password, click the appropriate user account on the Manage Profiles page, then click Send Password. Doing that sends the user an email; if the user clicks the link in the email, he or she will be taken to a page where they can reset their password.

Note. Although administrators cannot change a user’s password, they can use the entity.update API to force a user to reset their password. This is done by setting the user’s password to NULL (no password), and then sending them a reset password link. Users must then create a new password before they can log on. (However, and by default, users are allowed to simply reuse their old password.)

See Also

Deleting a User Profile

Nothing lasts forever, and that includes user profiles. Because of that, administrators have the ability to delete a user profile and, by extension, to prevent the affected user from logging on to the site (at least by using the deleted account). To delete a user profile:

  1. From the Manage Profiles page, click the user account to be deleted.
  2. On the Edit User Profile page, scroll to the bottom of the page and then click Delete Profile.
  3. In the Would you like to delete this profile? Dialog box, click Yes.

Clicking Yes deletes the account. By default, however, that same user (or any other user) can create a new account using the same email address, display name, password, etc. To prevent people from using a specific account (for example, if you don’t want anyone logging on as, don’t delete the account; instead, set the deactivateAccount attribute of the account to the current date and time (or, technically, any day and time). If anyone tries to log on using a deactivated account that logon attempt will fail:

The Account Deactivated Screen

In addition to deleting an occasional “bad” profile, you might also want to delete stale user profiles (this helps minimize the size of your user database). For example, if you search on the lastUpdated attribute, you can determine which users have not logged on in, say, the past 6 months (the lastUpdated attribute is changed each time a user logs on.) You can then delete those stale user profiles one-by-one.

See Also

Exporting Audit Data

Whenever a change is made to a user profile, information about that change is written to the Console audit log: any action that creates, deletes, or modifies a user account in any way is recorded in the log:

type c5ukftq8n6fene4mgw6bvbhb5vj87rps,,,,
277a966f-37e6-4ce8-9abc-61b77ca6ae3f,,TBD dragons,kskmfn2sxu4ysuvrzv8cs57wa53rzums,

If you look closely, you’ll see that this audit log entry (and all audit log entries, for that matter) contains the attributes detailed in the following table (although, depending on the change and who made it, not all the attributes will contain values):

Name Show Audit Data Description
agent_capture_client_id Change By ID of the API client associated with the API call. This is the same ID found on the Manage Properties page. For example:

agent_email Change By Email address of the agent who made the change. This attribute will be blank unless the task was carried out by a Console agent. For example:
agent_id Reserved for future use.
agent_label Reserved for future use.
agent_uuid UUID of the agent who carried out the task. This attribute will be blank unless the task was carried out by a Console agent. For example:

origin_component Reserved for future use.
signed_data_client_description Description of the signing client. This attribute will be blank unless the task was carried out by a Console agent. For example:

signed_data_client_id Client ID used to sign any ancillary data delivered along with the logdata header interface. This attribute will be blank unless the task was carried out by a Console agent. For example:

target_capture_application_id ID of the application used when making the API call; application IDs can be found on the Manage Application page. For example:

target_capture_entity_type Name of the database schema (i.e., the entity type) that was updated. For example:

target_capture_uuid UUID of the user profile that was modified. For example:

target_field_current_value New Value New value assigned to the modified attribute. For example: 2017-09-25 15:20:52.18615 +0000
target_field_path Field Changed Name (path) of the modified attribute. For example:

target_field_previous_value Previous Value Value that was assigned to the attribute before the modification was made. For example:

2017-09-21 20:14:32.532408 +0000
transaction_committed Time Updated Date and time the modification took place. For example:

2017-09-25T15:20:52Z 00
transaction_id Reserved for future use.
type Type of operation performed: create, update, or delete. For example:


Note. In the preceding table, the Show Audit Data column corresponds to the columns used when you choose to display audit data onscreen instead of downloading that data.

Good question: how do you get access to all this log data? In the Console, you gain access to log entries by exporting audit data for a user (you can only export audit data for a single user at a time). To export this data, and to view the data onscreen, complete the following procedure:

  1. From the Manage Profiles page, click the user profile containing the audit data you want to export.
  2. From the user profile Edit page, click Export Audit Data:
    Exporting Audit Data
  3. On the Export Audit Data tab, select a time interval (30 days, 60 days, 90 days) for the export.
    Selecting Audit Dates
  4. Click Show Audit Data. The audit data is displayed onscreen:
    Sample Audit Data

As you can see, the onscreen display includes only a handful of audit data fields (although, arguably, these are the fields you’re probably most interested in). Despite that seeming-limitation, Janrain strongly recommends viewing audit data onscreen whenever possible. Why? Because audit data always includes personally-identifiable information (PII). The chances of someone stumbling upon PII that they shouldn’t have access to is lessened if that data is displayed onscreen (and then disappears from sight when you access another page in the Console). By comparison, downloading and saving CSV files, each file containing PII, increases the chances of that data being exposed.

If you need to download data, however, you can complete the same procedure and then click Download CSV File instead of Show Audit Data. Clicking Download File downloads audit data to a comma-separated values (CSV) file with a name similar to this:


In the preceding file name, f467d27a-e4f1-4c1b-bd18-24d47b6ac3f8 indicates the UUID of the user whose audit data was exported.

Note. We should also mention that the CSV file is downloaded directly to the Downloads folder configured for your web browser. You cannot save the file to any directory other than that.

When downloading audit data, as we saw previously, you can export all audit data for the last 30 days, the last 60 days, or the last 90 days.

In addition to those predefined intervals, the Select Dates option enables you to pick a specific time interval for downloading audit information any time within the last 90 days; for example, you might choose to look at audit activity that took place only between March 1, 2018 and March 8, 2018.

Selecting Audit Dates

To return data for a specific time range, click Select Dates and then click the Start Date calendar icon to display the date picker:

Selecting Audit Dates

Click a start date, then repeat the process to select an end date.

Note that, when you display the date picker, you’ll initially see a calendar only for the current month:

Selecting Audit Dates

Does that mean you’re limited to time intervals that occurred only in this month? No. If you want to set a date for a month other than the current one, just click the displayed month name (e.g., Mar 2018). In turn, you’ll see a list of months similar to this:

Selecting Audit Dates

To select a start date in, say, December, 2017, just click the appropriate month:

Selecting Audit Dates

And then click the start date.

If you look closely at the preceding calendar, you’ll notice that some of the days (e.g., December 11) are grayed-out; that’s also true in the month picker, where months like October 2017 and November 2017 are unavailable. Why can’t you select those dates and those months? There’s a good reason for that: audit data is only maintained for 90 days. That means that you cannot select a start date (or a start month) from 91 or more days ago.

Scroll ↓