Working with the Property Attribute
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:
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.