Administration › Email Administration › Mailbox Rules › Create a Mailbox Rule › Mailbox Rule Fields › Artifacts Use Considerations

Artifacts Use Considerations

An email artifact refers to something that arises from the mail process, for example, an email address that is included in a forwarded email. The Text API uses artifacts that contain a ticket ID (such as a reference number) for reply support. When the ticket ID is found, an existing Text API keyword (such as %INCIDENT_ID) is set and added to the input for the Text API. The Mail Eater identifies that a reply is associated with a particular ticket by finding the artifact in the message.

The Mailbox rules let you specify the artifact and the value that the Text API uses. For example, you can define a rule for incidents as Incident:{{object_id}}%. When a rule finds Incident:1234, the Text API uses %INCIDENT_ID=1234 (1234 is the ref_num for the Incident). Because the artifact must be unique in an email and easy to find, you can make the artifact more distinctive such as %Incident:{{object_id}}%. A percentage sign (%), whitespace, or some other character that cannot appear in an artifact value must follow {{object_id}}. Uppercase and lowercase letters, numbers, forward slashes, commas, and plus symbols are potentially part of a value. The secure artifacts are Base64-encoded after encryption. If you do not use the Secure artifacts, the characters that follow the artifact must not be contained in the ticket ID suffix, if any, which has been configured for that type of ticket.

When using the filter string of the mailbox rules to identify the ticket ID Artifact, the keyword {{object_id}} represents the position in the filter string where the ticket ID artifact is expected. This keyword is case-sensitive, even if the mailbox rule is not.

Example: Email Artifact Use

The following example shows an ARTIFACT format for use in a mailbox rule for a change request ticket.

Usage: %REQUEST=@{call_req_id.ref_num}%

Example: %REQUEST=1234%

When you construct the filter string of the mailbox rule, consider the following conditions:

• A clear boundary must exist between the ticket ID artifact and the keywords which precede and follow it. We strongly recommended that you include whitespace text in this boundary text.
• Do not end the portion of the filter string that precedes the {{object_id}} keyword in a repeatable or optional pattern that can match the beginning of the ticket ID Artifact, and do not end a pattern whose length is ambiguous. For example, the filter string must not contain the request(er|ed|ing)?{{object_id}}, because this construction causes an ambiguity whether a trailing er, ed, or ing is the end of the leading text or part of the prefix of an unprotected ticket ID.
• The portion of the filter string that follows the {{object_id}} keyword must not begin in a repeatable or optional pattern that may match the end of the ticket ID artifact, must not begin with a pattern whose length is ambiguous, and must contain at least one element of whitespace. For example:
  • The filter string must not contain {{object_id}}[A-Z]?, because the [A-Z]? may match the last character of the ticket ID artifact.
  • The filter string must not end with {{object_id}}Item, because it is possible for Item to appear in the ticket ID artifact, either as the suffix of a ticket ID in a plain-text or protected artifact, or as characters within a secure artifact.
  • {{object_id}} Item is acceptable, because the space cannot be part of a ticket ID artifact, and is not part of a protected or plain ticket ID artifact. However, {{object_id}}[ \t\r\n]+Item (open-bracket, space, backslash, t, backslash, r, backslash, n, close-bracket, plus sign, +Item) is better, because the [ \t\r\n]+ compensates for the mail program inserting a line break after the {{object_id}}.
• When you construct the filter strings for different mailbox rules, avoid using a filter string that completely includes another mailbox rule filter string, or in which the portion before or after a {{object_id}} keyword completely includes that portion of another mailbox rule filter string. Depending on the order in which these filters are checked, a message match intended for one filter can match with another, with a portion of the ticket ID artifact matching the additional text that distinguishes between the two filter strings.