組み立てはコレクションを引用し、人を待ちます。交渉も、CRM への書き込みもしません。

人の確認段階に使うワークフローキャンバス
取引の確認は、案内されたグラフと人です。このキャンバスは CRM ではなく、外へは何も送りません。

取引の確認

架空の条項を一つ確認し、人の決定を残します。手を動かす時間は約 30 分です。顧客へは送りません。

目的

確認者に、引用、矛盾、または欠落を見せられます。レベルは編集者と、名前のある確認者です。モードは保存型です。範囲は一つのワークスペース、例のコレクションだけです。

前提

harbor-note.txt はインデックス済みです。二つ目の架空ファイル harbor-conflict.txt も上げます。中身は次だけです。Harbor Sample delivery window is 30 days. 両方を抽出します。生きた契約は使わないでください。

サンプル

質問: What delivery window should Harbor Sample use? 既知の回答は 14 日のメモだけを使い、引用を期待します。矛盾は両方のメモの参照を確認し、確認者が一つの数を拒むことを期待します。沈黙は支払者を問い、決定が無いことを期待します。

手順

  1. コレクションで窓を検索します。確認者に見せる参照だけを確認します。
  2. 回答リクエストを書きます。状態が grounded なら、引用がパケットです。二つの窓が出たら、平均しないでください。
  3. ワークフローのキャンバスでは、決定として保存する結果の前に手動承認を残します。その承認ノードが既に承認されているときだけ、公開して実行します。無ければ、パケットの後で止め、決定は製品の外に残します。
  4. 確認者は accept 14 days、conflict、insufficient を選びます。この手順に送信ボタンはありません。

フィールド

決定いつ
accept 14 days引用が一つ、抜粋が 14 日、確認した集合に二つ目の窓が無い。
conflict確認した抜粋が食い違う。
insufficient抜粋が窓を述べない、または質問が支払者についてである。

例

{"deal":"HS-104","question":"What delivery window should Harbor Sample use?","decision":"conflict","citations":["14 days","30 days"]}

この JSON は確認メモです。Bundata の CRM 書き込みではありません。

回復

確認者が終える前に根拠が古くなったら、検索し直します。source_changed を返す参照のパケットは承認しません。14 か 30 へのモデルの好みは解決ではありません。

制限

自律的な交渉、CRM の更新、ワークスペースをまたぐ検索はありません。Deal Desk というテンプレートは、インストールされ、あなたが実行したときにだけ名前を出します。このクックブックは、それが入っているとは仮定しません。

確認

成功: 14 日だけのパケットには引用が一つあり、確認者が受け入れます。失敗: 両方のファイルを確認した記録は conflict であり、22 日へ混ぜた窓ではありません。