組織、アプリケーション、環境

組織はチームと請求を、アプリケーションはワークフローとAPIキーを保持します。本番とサンドボックスの環境を間違えると変更が反映されません。

#2つの階層

組織はあなたのアカウントです。以下を保有します。

• チームとそのロール
• 請求残高と請求書
• 監査ログ
• すべてのアプリケーション

アプリケーションは組織内のワークスペースです。以下を保有します。

• 独自のワークフロー
• 独自のAPIキー
• 独自のwebhookエンドポイント
• 独自のデータ保持ポリシー
• 独自のプロダクト（アプリケーションごとにプロダクトを有効にする機能が提供済みの場合）。プロダクトとその内容をご覧ください
• 2つの環境：本番とサンドボックス

アプリケーションは、サイドバー上部のアプリケーションカードから切り替えます。切り替えはすぐに反映されます。同じメニューからアプリケーション設定とアプリケーションを作成も開けます。

#これが見た目以上に重要な理由

「変更したのに何も起きなかった」という報告のほぼすべてが、この構造に行き着きます。

• セッションはアプリケーションBで動いているのに、アプリケーションAのワークフローを編集した。
• あるアプリケーションにwebhookエンドポイントを追加したのに、別のアプリケーションからのイベントを期待していた。
• トラフィックは本番で動いているのにサンドボックスを見ている、またはその逆。
• 呼び出そうとしているリソースとは別のアプリケーションのキーで呼び出しており、明らかに存在するはずのものに対して404や403を受け取っている。

他の何かをデバッグする前に、まずアプリケーションを確認してください。APIエラーとその意味をご覧ください。

#本番とサンドボックスは別々の環境

新しいアプリケーションは本番です。テストはサンドボックスで行います。サンドボックスは組織で共有されるテスト用アプリケーションで、独自のデータと独自のキーを持ちます。サイドバーのアプリケーション名の下にある本番とサンドボックスの切り替えで行き来できます。

検証、APIキー、webhook、リストは環境ごとに分かれています。ブランディングは共有され、ワークフローは一度構築すれば環境間でコピーできます。この分離こそが重要な点です。テストトラフィックと本番データが混ざることは決してなく、サンドボックスキーが誤って実際のクレジットを消費することもありません。サンドボックスでのテストをご覧ください。

#いくつアプリケーションを持つべきか

ほとんどのチームは1つから始めます。それだけで本番とサンドボックスの両方が使えます。それ以上は、独自の設定や独自の分離が必要なものごとに分けてください。

• 製品ごと。異なる製品が異なるワークフローと異なるwebhookエンドポイントを必要とする場合。
• プレプロダクション環境ごと。1つのサンドボックスだけでは足りない場合。
• ブランドごと。複数のブランドで異なるスタイルの検証を提供している場合。
• 保持ポリシーごと。保持ポリシーはアプリケーションごとに設定されるためです。

アプリケーションごとに分かれないものは残高です。これは組織レベルであり、すべてのアプリケーションが同じクレジットを使用します。

#追加のアプリケーションを作成する

サイドバー上部のアプリケーションカードを開いてアプリケーションを作成を選び、アプリケーション名を入力します（アプリケーションごとのプロダクトが提供済みの場合は、その用途も選択します）。選択肢が見当たらない場合や、コンソールではなくAPI経由で作成する必要がある場合、それはアカウントレベルの権限の問題であり、自己判断で回避するのではなくサポートに確認する価値があります。

#複数の組織

1人で複数の組織に所属でき、サイドバー上部の組織メニューから組織を切り替えられます。保留中の招待もそこに表示されます。自分で複数の組織を作成できるのはリセラーアカウントに限られ（有効にするにはサポートに連絡してください）、自分の組織の下にサブ組織やサブアカウントを作る方法はありません。自社の複数の顧客にサービスを提供する場合、サポートされる構成は1つの組織の中で顧客ごとに1つのアプリケーションです。各アプリケーションは独自のワークフロー、ブランディング、APIキー、結果、利用レポートを持ち、他から完全に分離されますが、請求は組織レベルにまとまります。

#Diditの再販

Diditを自社製品に組み込み、顧客に課金したい場合、それがリセラーモデルです。サポートが問い合わせた全員に伝えている条件は次の通りです。

• 前払いクレジット。 最低初回購入額は5,000米ドル、前払い、1年契約です。クレジットは失効せず、組織レベルに置かれ、あなたが獲得したすべてのエンド顧客で消費され、金額に応じて深くなるボリューム割引が付きます。
• ダッシュボードはあなたが構築します。 DiditのAPIを自社のフロントエンドに組み込み、顧客はそこでワークフロー、ブランディング、ロールを管理します。DiditはBusiness Consoleのホワイトラベル版を提供しません。エンドユーザーが見る検証画面にはあなたのブランドを付けられます（ホワイトラベルを参照）が、コンソールには付けられません。
• マージンはあなたのものです。 顧客が支払う価格はあなたが決めます。Diditは契約期間中固定の単価で、完了した機能ごとにあなたに請求します。
• ローカルパートナープログラムではありません。 Diditはデモ、オンボーディング、サポートを顧客と直接行っており、販売代理店や導入パートナーは募集していません。

再販を自分で扱いたくない場合は、代わりに紹介オプションを使ってください。Business Consoleで設定 → 紹介して報酬を獲得を開き、リンクを取得して共有します。紹介した組織が行うすべての現金入金に対して10%のコミッションを、初回入金から36カ月間受け取れます。Diditクレジットとして使うか、熟成期間後に銀行振込で受け取れ、納品やサポートの義務はありません。どちらに決める前でも、無料枠で連携を構築・テストできます。

#アプリケーションの削除

アプリケーションの完全な削除はまだ利用できません。アプリケーション設定には危険ゾーンがありますが、削除は利用できないと表示され、何も削除されません。それまでの選択肢は次のとおりです。

• 使用をやめる。 誰も誤って選ばないように名前を変更し（acme-oldなど）、開発者 → APIキーでそのAPIキーを取り消してください。
• 顧客データを消去する。 検証データは、アプリケーションのライフサイクルではなく、そのデータに対する保持ポリシーと削除ルールに従います。データを明示的に削除してください。セッションと個人データの削除をご覧ください。
• 最初からやり直す。 サポートは、新しい組織を作成できるように組織全体を削除できます。チーム、残高、履歴もすべて失われるため、最後の手段です。

#すべてに帰属先がある

すべての変更は、どのアプリケーションに属するかを監査ログに記録します。これが、複数アプリケーション構成を単に整理されたものにとどめず、監査可能なものにしています。監査ログの利用をご覧ください。