Invoke WorkflowとInvoke Workflow Interactiveの使い分け
■まず結論から
UiPathには、Workflowから他のWorkflowを呼び出す機能が2つあります。
Invoke Workflow Fileと、Invoke Workflow Interactiveがそれです。
説明には、～ Interactive のほうは、「必要に応じて対話型の Windows セッションを強制します」と書かれていますが、具体的な違いはこれだけではわかりにくいかもしれません。
結論から書くと、「ExcelやWord、IE等のブラウザを使う場合、あるいはFind Image等の画像認識を行う場合は、一度Invoke Workflow Interactiveを使うべき」となります。
ですが、その理由を理解しているとUiPathのロボットを運用する上でのトラブルを減らすことができますので、技術的な背景について記載します。
■ 対話型セッションとバックグラウンドセッション
まず、前提として、「Windowsのセッション」が何かについて、端折った説明をします。
ざっくりと「セッション」＝「複数ユーザーが同時にログインできるOSで、それぞれのユーザーに割り当てられた領域」と考えてください。つまり、AさんとBさんが同時に同一PCのWindowsにログインして作業をするとき、メモリ内のデータが混ざったら大変なので、それを切り分けるための単位、ということです。
さて、RPAで気にするべき「Windowsのセッション」には、「インタラクティブ（対話型）のセッション」と「バックグラウンドで動く画面のないセッション」があるということです。
「インタラクティブ（対話型）」というのは、メモリ内に画面領域がしっかりと用意され、ウインドウ等の表示を司る機能がフルに動作する状態を指します。
ですので、普通にユーザー（人間）がログインして使うときは、基本的に対話型セッションになります。画面等が表示されなければ操作は困難だからです。
しかし、バックグラウンドで動くだけのアプリケーションであれば、画面が表示されないセッションのほうが、処理やメモリへの負荷を節約できる、という利点もあります。ですので、ロボットはそういったセッションで起動されることがあります。
上記のような違いがあるので、Invoke Workflow Interactiveは、もし実行中のロボット（Workflow）が対話型セッションでなければ、対話型セッションを作成した上で、そちらで動作する、という挙動になります。
この動作には利点と欠点があるので、それを次に順に説明します。
■ Invoke Workflow Interactiveの利点と欠点
まず、対話型セッションを強制的に立ち上げる利点は、対話型セッションを前提に作られているアプリケーションの動作精度が上がることです。たとえばMicrosoft Office等は、もともと対話型セッションで使用されることを前提に作られているので、バックグラウンドセッションでは動作に悪影響が出る可能性があります。
（参考： Office サーバー サイド オートメーションの危険性について ： Japan Office Developer Support Blog ）
ですから、何かしら画面の動作が発生したり、あるいはFind Image等、画像認識等を使用する場合は、対話型セッションを使用するほうが無難です。
尚、Invoke Workflow Interactiveを一度呼び出せば、その中で行われる処理は対話型セッションであることが強制されますので、更にWorkflowを（入れ子のように）呼び出す場合、そちらはInteractiveを使用する必要はありません。
次に、Invoke Workflow Interactive、すなわち対話型セッションへの移行が行われる（かもしれない）Activityの欠点について。まず1つは、余分なオーバーヘッドが発生することです。前述のように、バックグラウンドセッションのほうが動作は軽いので、それで事足りる処理しか行わないのであれば、Invoke Workflow Fileのみで処理するほうが効率的です。
そしてもう1点。対話型セッションへの移行が行われる場合、それは別のセッション（メモリ内の作業領域）になるので、メモリ上の全てのデータが移動できるとは限らない、ということです。
これは何を意味するかというと、引数（InやOutに設定する値）のうち、値として固定できないもの（もう少し専門的な用語だとSerializableでないもの）は移動できません。具体的には、「DBへの接続（Connection）」や「Browser関連のActivityにある、ブラウザオブジェクトそのもの」等です。これらはUiPathの変数には「メモリ内の位置」として記録されているので、別のセッションからは値が読めなくなります。
逆に、値として書き出せるもの（Int32やString、Boolean型に代表される、一般的な変数値）は、「メモリ内の位置」ではなく「値として引き渡せる」ので問題なく引数で渡せます。つまり、Invoke Workflow Interactiveを使用する際は、使える引数の型に多少の制限がかかる、ということです。
（かなりプログラミング寄りな内容ですが、参考として ： .NETにおけるオブジェクト シリアル化 ）