在cc的情况下，存在固有的系统规则来减少就单个请求发送给用户的重复电子邮件通知的数量，并确保内部注释保持私密性。然而，这些规则可能不会完全消除重复的电子邮件——用户仍然可能会收到一些重复的电子邮件。
系统票证规则有时会抑制业务规则中的操作。它们不能被更改或覆盖，并规定支持的标准行为(请参阅关于系统票证规则）.它们有时会使整个触发器和自动化失败，或者某些操作未能执行，但这并不是错误。
本文包括以下部分:
- 关于业务规则动作抑制
- 抑制CCs通知的标准
- 没有电子邮件地址的请求者配置文件
- 了解自动化如何影响评论隐私
- 了解“公开CCed终端用户的电子邮件评论”的影响
- 了解业务规则操作抑制如何影响Events日志
相关文章:
关于业务规则动作抑制
的Email用户+(请求者和cc)动作与触发器和自动化中的其他动作不同——它被设计成以模仿常规电子邮件行为的方式向最终用户发送消息，这样最终用户就不会觉得他们收到了非个人的系统通知。
然而，这个动作在某些情况下是被抑制的(参见抑制CCs通知的标准）.如果被抑制，则触发器或自动化仍然触发，并且触发器或自动化中的其他操作仍然执行。只有Email用户+(请求者和cc)部分触发器或自动化被抑制。
抑制CCs通知的标准
当向票据添加私人注释时Email用户+(请求者和cc)触发器和自动操作被抑制。如前面所述关于业务规则动作抑制，只有Email用户+(请求者和cc)行动受到抑制。触发器或自动化仍然触发，并且触发器或自动化中的其他操作仍然执行。
的Email用户+(请求者和cc)当通过电子邮件更新(而不是创建)票证时，操作也被抑制，并且满足以下任何一个条件:
- 电子邮件的作者是请求者或抄送者。
- 请求者被挂起。
- 每个收到通知的人都已经收到了更新门票的电子邮件。
没有电子邮件地址的请求者配置文件
任何没有与其用户配置文件关联的电子邮件地址的用户在任何情况下都不会收到通知。这是不可能的，因为支持人员不知道将消息发送到哪里。
如果机票上的请求者没有电子邮件地址，则Email用户+(请求者和cc)触发器和自动化操作被抑制，因此根本不会发送电子邮件通知。这意味着，即使票上的cc在他们的用户资料中有一个电子邮件地址，他们也不会收到通知。
了解自动化如何影响评论隐私
的自动化时电子邮件用户在一张私人机票上发生了这些事情:
- 如果用户是管理员、座席或组，则发送邮件通知。如果是终端用户，则不发送邮件通知。
- 任何形式的评论(公开或私人)都不会被添加到门票中。
- 事件记录在事件日志中。
了解“公开CCed终端用户的电子邮件评论”的影响
的Email用户+(请求者和cc)在某些情况下，动作被抑制取决于是否公开CCed终端用户的电子邮件评论选项已启用，并且满足其他条件。以下场景说明了这种情况何时发生。
场景1
这Email用户+(请求者和cc)当公开CCed终端用户的电子邮件评论是启用所有这些标准都满足了:
- 门票正在通过电子邮件更新(而不是创建)。
- 电子邮件的作者是请求者或抄送者。
- 每个收到通知的人都已经收到了更新门票的电子邮件。
场景2
的Email用户+(请求者和cc)当公开CCed终端用户的电子邮件评论是禁用并且票正在通过电子邮件更新(而不是创建)，并且满足以下任何一个条件:
- 电子邮件的作者是请求者或抄送者。
- 每个收到通知的人都已经收到了更新门票的电子邮件。
了解业务规则操作抑制如何影响Events日志
本节解释业务规则动作抑制如何影响Events日志。
如果Email用户+(请求者和cc)被抑制，并且触发器或自动化不包括任何其他操作，则Events日志中不会记录任何事件，即使触发了触发器或自动化。当没有其他动作时，除了Email用户+(请求者和cc)在业务规则中，Events日志中没有关于注释的任何内容。例如:
如果Email用户+(请求者和cc)被抑制，并且触发器或自动化包含其他操作，则执行其他操作。然后，在Events日志中记录关于其他操作的事件。当通知之后的规则中存在另一个操作(例如添加的标记)时，它将执行并且两个操作都显示在Events日志中。为例。
6个评论
在这张图表中是什么意思?这些列表示什么?为什么有些行包含结果，有些则没有?我觉得好像少了一堆标签什么的。我完全不知道该如何解释这一点。
第一行是否意味着如果启用了MECFCEUP(将抄送的最终用户的电子邮件评论公开)，并且请求者通过电子邮件更新票证，则触发将发送请求者并抄送电子邮件通知(例如:“嗨，谢谢你的回复，我们的数据中心正被蜜蜂包围，所以我们的回复时间很长，坚持住!”并保持票证打开)不会触发电子邮件通知，因为“每个收到通知的人都已经收到了更新票证的电子邮件”?
这是从图表中得出的合乎逻辑的结论，但这肯定是不对的。
嘿CJ !我们正在更新本文的布局，以便使表中的信息更容易理解。
如果您单独查看每个列(除了第一个列)，则该列的每个单元格中的单词是相同的。这一栏是为了表示形势的特点。如果单元格中有-，那么该特性不适用于该情况。
这个想法是，您可以使用表来比较不同的场景，但它肯定不是最直观的!
如果看第一行，那么邮件用户+请求者和cc在以下情况下，触发器和自动化中的动作被抑制:
因此，在您提供的示例情况中，您是正确的:电子邮件通知将被抑制。如果你想看到这个工作不同，我建议张贴你的反馈到我们的对支持页面的反馈供我们的产品经理审查和其他社区成员查看。
嗨。
这几天我一直在努力理解这个抑制规则……我的情况是，我想使用{{ticket. comments_formatting}}当最终用户向我们发送电子邮件时，他/她的回复是创建了一个票，应该包括他们写给我们的内容。当我们使用“评论时通知”和“解决时通知”时，占位符可以正常工作，如果我们手动创建一个票据，占位符也可以正常工作。但是当最终用户直接给我们发邮件时，他们不会得到问题的副本。
我们现在还没有启用帮助中心，我们启用了“任何人都可以提交票证”。
我们错过了什么?触发器起作用了，只是占位符不起作用了。
我们也尝试过使用{{ticket.description}}。
谢谢你的问题!
由于你所描述的情况还需要进一步调查，所以我需要查看一下你的账户。
我正在创建一个入场券，我们将把这个话题转移到那里。
谢谢你的理解。
嗨
我们添加了一个非常简单的触发器，当创建新票证时，会向请求者发送一封电子邮件，如下所示:
这个触发器在大多数情况下工作得很好，但非常偶然地没有被执行。我们试图找出其中的原因。如果票证是由邮件请求创建的，并且原始邮件的“发件人”(=请求者)邮件地址与邮件的“cc:”列表中显示的地址相同，则似乎不会处理触发器。我猜这是Zendesk系统的先天规则之一，它抑制了触发器亚博的执行。
事实上，如果请求者将自己的邮件地址放在抄送列表中，这可能没有多大意义。似乎有些用户喜欢这样做是一个事实。也许是为了确保邮件确实是由他们的邮件系统发出的。他们仍然希望得到Zendesk票务工具的回复，如果“from”和“cc:”拥有相亚博同的邮件地址，这是不可能的;-()。
你能确认我们观察到的触发反应吗。通知行为是由Zendesk的固有规则引起的吗?亚博
谢谢
Juergen
由于这种行为，我将为您创建一个罚单。请等待我的邮件更新，让我们从那里开始。
干杯!
请登录留下评论。