Mike Larsen

Our Team Members page does not yet have the Brand column and there is no way I can find to modify an agent's brand assignment. A previous version of this page indicated the feature was being rolled out by Pod - I believe the date for our Pod has passed a week ago. 

So, where is the feature? We are eager to look at it.

We are seeing this, but in a different circumstance. Our agent is continuously a member of the group - so, again, it is NOT that we removed the current assignee from a group.

Instead, the “system” makes the assignee empty (it clears the assignee). This happens thusly:

• a WhatsApp channel ticket has an assignee and then is marked as solved (or pending)
• the end user adds a message/comment
• a WhatsApp channel ticket changes back to open (from pending or solved)
• throughout, the agent has remained a member of the group and remains online
• the assignee changes from the agent to blank/unassigned

To be clear, we want the assignee to remain unchanged so the agent is still the assignee and the ticket is NOT unassigned.

We believe the agent was online throughout. In fact, we are seeing cases where the agent marks a ticket as solved and then the user responds shortly after while the agent is still viewing the ticket. But of course the agent must reassign the ticket to themselves.

The system does this action. We review the tickets' history and see the fingerprint of the ‘system’ - there is no trigger or other rule that does this. And I've looked at system settings and find no setting that would do this sort of reassignment. I thought maybe the agent was somehow “offline” and the system determined an “online” agent should have the opportunity - but this seems to not be the case.

Why does the system take the assignment away from the assignee agent when a WhatsApp ticket transitions from Solved or Pending back to Open?

Our support team would like this too. A sound as part of a notification would allow agents to quickly realize a ticket has been created or updated. It would lead to quicker response and quicker resolution.

Light Agents and Full Agents are different enough - very different actually. It seems incomplete to only report and filter on admin, agent, end user. We have a need to separate Light Agents from other agents in reporting in Explore.

And while we are discussing Light Agents... It would also be a nice feature to be able to create and name multiple roles which are each Light Agents. Each role could have the same permissions (so as to honor the seat type of the Light Agent and its limits relative to a full agent).  For instance, we might have two full agent roles which are identical but are named differently and collect cohorts of agents - we cannot do the same for Light Agents. So all Light Agents are in the same role. Permissioning is usually okay, but organizing agents is limited. But there are a few permissions for Light Agents (tickets they can access, manage suspended tickets, reports permissions) which, for a large support team like ours, might be better to NOT apply universally. In other words, one cohort of agents might need reports access while another should not have no reports access.

Thanks Eric

I can see how this can work. fieldGetter is important and the if/try logic is too.

Just making some notes here...

- For our needs, we'll have one field. So "metadataField" rather than one for ip and another for client
- 123 should be replaced with the specific field ID in "(obj) => obj.id === 123", e.g. field id 7779379345427 in the sandbox.
- I wonder if there is a way to base it off the field NAME instead. That way we have one implementation for both our sandbox and production environment. Perhaps obj.name or something. Both environments will have a field named "Metadata", but the field ID will differ in both because it is auto-assigned.
- Yes, this is meant to sync just one comment - the first comment, which may be from the end user and tends to be the most useful/interesting.

Thanks again. We'll try it out and maybe ask for some more advice or report good news.
-Mike

We find metadata to be interesting and helpful. But the metadata is a bit hidden within the comment and it cannot be shared to another application (e.g., Jira) because it is not a field.

So our goal is some combination of the following
- modify the value of a custom field, named 'Metadata' and would have a specific Field ID
- upon ticket creation, the field would receive the metadata value(s)
- if for some reason the field already holds a value, do not overwrite
- upon subsequent edits to the ticket or comment additions, do no change or modify the field

The metadata values of interest:
metadata.system.client
metadata.system.ip_address
metadata.system.location

And the value written to the field would look something like:
Browser Client: {browserClient}
IP Address: {ip}
Location: {location}

We've found a custom app and modified it slightly to better suit our needs. But the app just appends the metadata to a comment rather than to a field. And the metadata is added to each and every comment. We just want to put the first comment's metadata into a field and that's all. The custom app is here and it works (but with the limitation mentioned):
https://github.com/eric-at-zd/metadata-writer

Is anyone up to create a version of the app which modifies a specific field? If we had the code, we could generate our own version of the custom app which modifies our specific field (by Field ID or by field name).

Thanks!