Note. This article applies only to Customer Care Portal users.
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:
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.clientIDattribute. 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:
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:
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:
However, suppose you change the user’s Property attribute to EMEA Login Client. In that case, the message references the EMEA Login site instead:
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.