Plan requirement
| App | Knowledge Capture Actions |
| Subscription | Any Zendesk Support plan |
| Access | Admin |
Which article labels the app understands, and what each one does to the ticket when an agent inserts that article.
How a label is built
Two parts: the action, and what it acts on.
- Action. What should happen to the ticket.
- Identifier. The ID of the thing, or the tag to add.
You put the label on the help centre article. When an agent inserts that article into a comment through Knowledge Capture or Knowledge Share, the app reads the labels and acts.
The labels
| field_12345_value | Set custom field 12345 to the option with the tag value. Can be used more than once. |
| form_12345 | Set the ticket form to form 12345. Once per article. |
| group_12345 | Set the group to group 12345. Once per article. |
| assignee_12345 | Assign to user 12345. Once per article. |
| tag_something | Add the tag something. Can be used more than once. |
| macro_12345 | Apply macro 12345. Can be used more than once. |
Once against more than once
A ticket has one form, one group and one assignee, so those labels only make sense once. Fields, tags and macros can stack, because a ticket can carry several.
What this is really for
The article already tells the agent what to do. These labels make the ticket agree with it: the answer about returns also sets the category to returns, so your reporting matches what actually happened without the agent remembering to set it.
IDs, not names
Every identifier is a numeric ID. Renaming a group or a form does not break anything; deleting one does, and the label then points at nothing.
Worth checking the labels when you clean up forms or groups, because nothing warns you.
Start with one
Put a label on a single article, use it, and look at the ticket. Labelling fifty articles before testing one is how a wrong field ID ends up on all fifty.
Comments
0 comments
Article is closed for comments.