When it comes to Console agents, what’s good for the goose isn’t necessarily good for the gander. For example, by default all agents see the exact same fields any time they conduct a user search; that means that everyone who runs a Console search sees results similar to these:
Of course, you can modify which attributes are displayed in the search results; for example, instead of the default values (givenName, familyName, email, primaryAddress.phone, birthday, and created) you can show a completely different set of attributes:
That’s up to you.
The point is that, regardless of which attributes you display in the search results, by default each agent who logs on to the Console will see those same attributes. For example, suppose you replace the displayName attribute with the primaryAddress.phone attribute. In that case, all of your agents will see the new attribute in their search results. One for all, and all for one.
So is that a problem, the fact that all your agents see the same fields when conducting a search? Well, it might not be a problem, but it might not be ideal, either. To go back to the goose/gander analogy, there’s a good chance that different agents in your organization have different jobs and different responsibilities. Because of that, it might be better if those agents saw different attributes in their search results.
For example, suppose you’re an agent who only works with profiles for US residents. In a case like that, seeing a column labeled Country is superfluous: based on your role, the only profiles you can access are profiles from the US. Seeing the primaryAddress.Country attribute doesn’t add much value; after all, every single entry in that column is going to read exactly the same:
In other words, seeing a different attribute – maybe, primaryAddress.city or primaryAddress.state – would probably be more useful than seeing an unending string of the exact same value.
So is there anything you can do about this? Well, now that you mention it, there is: you can assign agents to groups, then specify a different set of search result attributes for each group. For example, agents in Group A might see the following fields when they do a user profile search:
Meanwhile, agents in Group B might see a different set of fields:
The difference in the search result fields has nothing to do with the role held by an individual agent. Instead, the difference is dictated by the group that the agent belongs to.
Before we go any further we need to mention that, at this point in time, agent groups must be created by Akamai (in the future, you will probably be able to create your own groups). If you want to implement agent groups, start by contacting your Akamai representative, and provide them with the following information:
The name of each group (you can have multiple groups, with each group associated with a different set of search display attributes).
The entity type (e.g., user) associated with the group. Groups can only be associated with one entity type.
The attributes you want to display (for example, primaryAddress.country).
The title for each search result column. For example, you might want to label the primaryAddress.address1 column Street Address:
In other words, you must supply data similar to this in order to create a group called North American Agents:
|Group name||North American Agents|
|Displayed attributes||givenName; familyName; primaryAddress.country; primaryAddress.phone; created; login|
|Column names||First Name; Last Name; Country; Phone No.; Registration Date; Last Login date|
After your groups have been created, you’ll see a new Groups section any time you access the Create Agent or the Edit Agent pages:
To assign an agent to a group, open the agent account and then complete this simple procedure:
- Select the group you want to assign the agent to.
- Save the agent profile.
If you change your mind later on, simply repeat this procedure, selecting None as the agent group and then saving the agent profile.
By default, agents can only be assigned to a single group. However, in some cases, it might be possible to assign a single agent to multiple groups. For more information, contact your Akamai representative.
There are at least two things to keep in mind when working with agent groups:
Agent groups only dictate the attributes displayed in the search results; they do not determine the profiles that an agent has access to. For example, you can use agent groups to prevent an agent from seeing the primaryAddress.Country attribute in the search results; however, you cannot use groups to prevent an agent from accessing profiles from a specific country or set of countries. To limit agent access, see Restrict agent activity by profile type.
If you assign an agent to a group you still need to assign that agent a role: groups supplement agent roles but they do not replace agent roles. If you assign an agent to a group but do not assign that agent a role, you’ll see the following error message when you try to save your changes:
It’s also worth reiterating that each group is associated with a single entity type. For example, let’s say you assign an agent to a group associated with the user entity type. When that agent searches for user profiles, he or she might see custom search fields like these:
However, when that same agent accesses a different entity type, they’ll see the default search display attributes for that type:
Updated over 1 year ago