使用"解决方案"来更新它，我们发现这与安坎关于自定义角色的建议相辅相成：

-我们为与会者创建了一个自定义角色，可以在访问中用作"参与方"

-我们在访问中将"参与方"选项卡重命名为"与会者"。

-我们从视图中隐藏了标准的"与会者"标签。

-我们使用Data Workbench将所有（常规）参与者的角色更改为我们的（自定义）参与者角色

此后，我们认为我们已经解决了问题，但是在某些情况下，标准的"参加者"字段会自动填写，并且邀请仍然发出。 所以另外

-我们实施了PDI解决方案，可以在保存访问记录后将所有（常规）与会者移除（事件保存前）

 foreach（this.AttendeeParty中的var参与者）{
  与会者.Delete（）;
 }
 

缺点是，这也与Outlook中创建的访问混在一起。 但是与我们的方案一样，我们仅使用C4C进行内部访问文档，而使用Outlook向客户发送约会（如果需要，则需要两个单独的Outlook cal。条目），这对我们来说不是问题。

安坎，

有关此问题的更新：我们将再次删除自定义角色，因为这会使现在不得不考虑多个参与者角色的销售代表的UX恶化。 此外，自定义角色不适合以应管理联系人的方式在Outlook中进行处理。

我与SAP CX上的其他各种SAP客户端进行了交谈，他们对我们的期望与我们相同，因为他们希望阻止自动发送任何邀请。 许多访问实际上是在仅出于文档目的而使用访问之后才遵循在系统中创建访问的过程（->不再希望发送邀请），并且大多数根本不向其客户发送任何邀请（通常是 行为方式是销售代表为他/她自己创建一个日历条目，而客户则单独创建他/她自己的条目。

我们将就此事与您联系。

亲切的问候

Dominik

此行为的设计考虑到以下事实：对于服务器端，没有客户端界面可以让您"手动按'发送'"。

如果期望用户进入并打开日历中的每个约会以检查邀请是否已发出，我会感到惊讶。 对于客户端-我们有一个界面（在任务栏中），您可以在其中进行批量操作。

有两种解决方案：

1。 将自定义字段（KUT）用于内部注释。 标准便笺字段与Outlook交换并在外部共享。

2。 考虑使用选项"电子邮件集成">"组件设置">"设置">"冻结描述字段"
使用此选项仅在创建时同步注释字段，并且后续更新不会同步。

Dominik，您好！

感谢您进行更新。
尽管您提到的过程在您的情况下可能很有意义，但我们有相等（实际上更多）的用户在处理约会时同步约会 它们，而不是过去，并且也希望邀请出去。

而且，不共享邀请不是我们目前计划的设置（或者，如果我说实话，根本不希望这样做）-期待结局- 用户打开每个同步事件（手动浏览日历？），然后打开每个事件以检查事件的发送状态，然后发送，这并不是一种简单的用户体验。 任何增加手动步骤的过程都是用户希望避免的另一种复杂情况：)

创建另一个角色不应让UX恶化，在我看来，这是正常的系统功能-系统预先交付了多个 角色。 实际上，我的建议是明确命名该角色，以便用户可以清楚地看到使用该角色时不会发出邀请。

问候，
安坎

嗨安坎，

有关此问题的更新：我们将再次删除自定义角色，因为这会使现在不得不考虑多个参与者角色的销售代表的UX恶化。 此外，自定义角色不适合以应管理联系人的方式在Outlook中进行处理。

我与SAP CX上的其他各种SAP客户端进行了交谈，他们对我们的期望与我们相同，因为他们希望阻止自动发送任何邀请。 许多访问实际上是在仅出于文档目的而使用访问之后才遵循在系统中创建访问的过程（->不再希望发送邀请），并且大多数根本不向其客户发送任何邀请（通常是 行为方式是销售代表为他/她自己创建一个日历条目，而客户则单独创建他/她自己的条目。

我们将就此事与您联系。

亲切的问候

Dominik

大家好，

我们正面临类似的情况，因此非常希望能够选择是否自动邀请。

最诚挚的问候

巴特

嗨安坎，

我了解可能有更多的用户想要同步并自动发送邀请，但是进行一些设置来控制此设置没有意义，因此可以根据个人客户的需要来激活或停用该设置 相应地？

最好的问候

亚历山大