IM-Workflowのアクション処理を実装する際の制限事項として、以下が明記されています。

=====
アクション処理は、IM-Workflow モジュールのトランザクション内で実行されるため
このプログラム中ではDBトランザクション制御を行うことはできません。
=====

これは具体的にどのような制限があるかというと
アクション処理内部でトランザクションを開始できないことはもちろんなのですが
もう一つ、実装側としての縛りがあって、ワークフロー処理系のAPIも
該当するということです。

以下は業務要件の事例ですが、ある承認処理に付随して
関連する案件の同期ノードや分岐ノードを自動承認させたいような
利用シーンがあった場合、処理疎通ケースを念頭に設計・実装しようとすると
承認対象の処理ノードに対するアクション処理にて、自動承認のために
承認実行用のAPI(ProcessManager)を利用しようと考えるわけです。

しかし、承認APIの内部では独自にトランザクションを開始する処理が
含まれるため、アクション処理内では利用できないことが発覚するわけです。

上記載した要件下にて、自動承認処理の契機はどうしてもアクション処理内で
実行したいケースがありまして、弊社では以下の方式で検討してみました。

案1.対象処理ノードの直後にシステムノードを配置する。
案2.対象処理ノードのアクション処理内で、承認処理APIを実行するジョブネットを実行する。

両案ともに対象のノード処理とトランザクションは分断されるため、本来やりたいことの
実現は可能です。
その上で案1,案2を比較した場合、案1側で実現した場合のデメリットを考慮し
より汎用性の高い、案2での実装を検討しました。

・案1方式でのデメリット
　対象の処理ノードが複数存在する場合、全ての対象ノードの直後にシステムノードを
　都度配置する必要がある。

なお、ジョブネットの実行については、以下のintra-mart APIを呼出すことにより、実現可能です。
JobSchedulerManager#execute

類似要件の参考になれば幸いです。