Workflow Engine
Lead →
Deal →
Quote →
Order →
Invoice →
Payment →
Reconciliation →
Renewal
Synced
All systems
Active
12 workflows
Audit trail
100% logged
One workflow engine. One audit trail. One source of truth.
1000以上のバックオフィスチームに選ばれています
HHubSpot
SFSalesforce
SShopify
StStripe
SlSlack
QBQuickBooks
XeXero
NSNetSuite
Salesforceの商談を受注・請求まで接続するワークフロー
Salesforceのデータが価値を持つのは、商談がそのまま受注・請求・在庫・入金の運用に繋がるときです。Sankaは、Salesforceレコードを統制されたワークフロー層に接続し、マッピング、承認、監査証跡を一貫して運用できるようにします。
同期
取引先・取引先責任者・商談・カスタムオブジェクトを、運用可能なデータモデルに取り込みます。
自動化
定期インポートやイベントトリガーで、受注・請求などの次工程をワークフロー化します。
統制
例外の承認と監査証跡で、割引・支払条件・上書きの判断を説明可能にします。
接続できる範囲と標準化ポイント
- Workspace > IntegrationsからSalesforceを接続（OAuth）
- 主要オブジェクトのインポートとプロパティマッピング
- 商談IDなどのユニークIDを運用レコードに保持し、再実行でも二重作成しにくい設計にする
- ステージ変更、受注作成、入金などのイベントをトリガーとしてワークフローを構築
| Salesforceレコード | Sanka側 | 重要になる理由 |
|---|---|---|
| 取引先・取引先責任者 | 会社・連絡先 | 顧客マスターの整合性を保つ |
| 商談（Opportunity） | 受注の起点 | 請求・在庫・回収への引き継ぎを標準化 |
| カスタムオブジェクト | カスタムオブジェクト（またはマッピング先） | 独自プロセスをシート無しで運用する |
よくある自動化パターン
- 商談 → 受注 → 請求: 商談を受注に取り込み、受注作成をトリガーに売上請求書を作成。
- 商談 → 在庫引当: 成約見込みのタイミングで在庫を引当し、例外を見える化。
- 例外の承認: 割引率、支払条件、手入力の上書きなどを承認回付。
[OK] Opportunity "Acme" が更新
-> 受注へインポート
-> 請求書を下書き作成
[待機] 承認が必要: 支払条件の例外
[承認] 財務
-> 監査証跡付きで継続実行
CRMの変化に強い連携
新しい項目やオブジェクトが増えても、統制があると自動化は予測可能になります。
マッピング
Salesforce項目とSankaプロパティを対応付け、複数のワークフローで再利用します。
承認
高リスクの変更だけを承認対象にし、運用を遅くしない設計にします。
可観測性
失敗・リトライ・データ品質の問題を早期に見つけ、根本原因を潰します。
導入手順（最短）
- 接続: Workspace > IntegrationsでSalesforceを認可します。
- マッピング: 商談・顧客・受注・請求に必要な項目を対応付けます。
- 1つのワークフローから: まずは「商談 → 受注 → 請求」で検証します。
- 統制を固める: 例外の承認と監視の責任者を決めてから拡張します。
参考:
よくある質問
カスタム項目やカスタムオブジェクトも扱えますか？
はい。カスタム項目はSankaのプロパティに対応付け、必要に応じてカスタムオブジェクトも取り込み、ワークフローの入力として利用します。
インポートや自動化で二重作成を防ぐには？
商談IDなどのユニークIDを保持し、再実行しても二重作成しない設計（冪等性）を前提にワークフローを組みます。
最初に何を自動化するのが良いですか？
商談から受注・請求への引き継ぎが最も効果が出やすいことが多いです。マッピングと監査証跡が安定してから、在庫や決算へ広げます。
Salesforce側の権限で注意すべき点は？
連携ユーザーが参照する項目の権限（フィールドレベルセキュリティ）を確認し、必要な項目が「表示」「参照」可能になっているかを先にチェックします。
