照理说一个无人值守的机器人原本是不应该有人工操作介入的，也就不会提供暂停功能。但客户可能出于业务需要，或者风险管控的考虑，会需要机器人具备暂停功能。通常，会希望在机器人运行时，用户摁下快捷键，机器人就马上暂停，而暂停之后也能够恢复。
那么如何在机器人执行正常业务流程的同时，检测快捷键是否被摁下呢？这里可以使用Pick(System.Activities.Statements.Pick)来实现这个效果。如下图如示。左侧只是用来模拟通常的业务流程，各位可以将自己实际的workflow放进去。右侧分支在Trigger中放入一个Monitor Events(UiPath.Core.Activities.MonitorEvents)用来同时检测快捷键是否触发。实际运行的时候，Pick的逻辑是这样的，两个分支的Trigger部分会并行执行(但其实各个分支的启动还是有细微的时间差的，这个在此先不讨论)，哪一个分支的Trigger先运行完毕，就会运行那一个分支的Action部分并且其它分支会停止执行。
既然我们已经能够在主流程运行的同时检测快捷键是否触发，那么我们接下来要解决的问题就是如何暂停（阻塞）主流程的运行。这里要注意的一点是，用户暂停后，应该也能够取消暂停状态继续执行，所以这里采用的方法一定要能够接收用户的输入。对此，我在Monitor Events中利用了Message Box，当然读者也可以根据实际情况选择其它具有类似作用的Activity。Monitor Events中的内容大致如下所示。我们可以看到，当用户摁下Ctrl+P时，机器人就会暂停并且弹出对话框提示机器人已暂停，一旦用户点击确定按钮，机器人就会继续运行下去。
我在主流程中做了一个无限循环打印时间的设计用来模拟实际的业务流程。机器人运行中摁下Ctrl+P在Output窗口中看起来的效果就是如下图所示这样。
要特别注意的一点是Monitor Events的属性中有一个RepeatForever一定要设为True，否则机器人只能暂停一次。。。
另外，当一个Workflow通过Invoke Workflow File去调用另一个Workflow时，调用方和被调用方（简称父子workflow）其实是运行在两个线程中的，而Message Box只能暂停自己所处线程的执行，因此要特别处理。一般来说，子Workflow未运行完毕时，父Workflow并不会继续运行下去，所以在子Workflow中实现暂停功能即可。