Agent Groups

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.