ウィザードの追加によるテンプレートの効率化
学習の目的
この単元を完了すると、次のことができるようになります。
- テンプレートにウィザードの質問を追加する方法を理解する。
- ウィザードの質問を追加して、テンプレートのファイルに他の変更を行えば、アプリケーションにダッシュボードを追加できることを説明する。
ダッシュボードが表示されていない問題の解決
この単元では、テンプレートと基盤となる機能に風味を加え、アプリケーションの味わいを深める方法について説明します。このモジュールではその手段として、ユーザーが CRM Analytics でアプリケーションをどのように作成したいかに関する質問を含む設定ウィザードをアプリケーションに追加します。この目的はテンプレートの素晴らしさを味わってもらうことで、あなた自身が次の手順を実行することはありません。ただし、各自のテンプレートをどのように使い始めることができるのかがよくわかります。
では、Service Performance ダッシュボードを追加するコードから始めましょう。元のテンプレートからはこのダッシュボードは作成されません。なぜでしょうか? まず、JSON ファイルがダッシュボードを参照しないためです。もう 1 つ理由があります。このダッシュボードは、DTC のカスタマーサービスがエンゲージメントの追跡に使用する Salesforce ケースオブジェクトからのデータに対して実行されます。元のテンプレートではケースデータがアプリケーションに追加されないため、このアプリケーションにはダッシュボードに入力するデータがありません。ケースを追加するロジックを追加する必要があります。
実行する手順は次のとおりです。
-
template-info.json
に Service Performance ダッシュボードと、テンプレートによってケースをアプリケーションに追加できるようにする上書きを追加します。
-
template-to-app-rules.json
に、ケースをアプリケーションに含めるようにテンプレートに指示するルールを追加します。
- 組織でケースオブジェクトを使用している場合は、パートナーがケースを追加できるようにするウィザードの質問で
variables.json
を修正します。(この質問は、テンプレートが Service Performance ダッシュボードをアプリケーションに追加するかどうかも決定します。)
-
ui.json
を編集して、ケースに関する質問をウィザードに追加します。
これらの各変更のコードは次のようになります。まず、以下は template-info.json
の元のバージョンのダッシュボード
セクションで、2 つのダッシュボード参照があります。これらの参照は、基本アプリケーションの 2 つのダッシュボードの JSON ファイルである、Exec_Overview_Pipeline_Performance.json
と Exec_Overview_Sales_Performance.json
をポイントしています。
次は、編集後のバージョンで、Exec_Overview_Service_Performance.json
への 3 つ目のダッシュボード参照と、ケースデータを参照する上書きがあります。
指定された変数に基づいてダッシュボードまたはデータセットを含めるようにアプリケーションに指示する条件ステートメントを template-info.json
に追加します。ここでは、この条件が、ユーザーがケースオブジェクトをアプリケーションに追加するかどうかを判断します (Constants.HasCases || Variables.Overrides…
)。つまり、ユーザーがアプリケーションを作成するときに、CRM Analytics は HasCases
という定数を探すことを意味します。この定数が存在する場合は、Service Performance ダッシュボードを追加します。ない場合は、ダッシュボードを除外します。この条件ではパートナーが選択できます。各自の組織でケースオブジェクトを使用して Salesforce でサービスのエンゲージメントを追跡している場合は、このオブジェクトを Execs Only アプリケーションに追加でき、Service Performance ダッシュボードが表示されます。
HasCases
定数はどこから取得するのでしょうか? template-to-app-rules.json
に空の定数セクションがあることを覚えている方もいると思います。
Variables.SObjectChoices
変数に基づいてケース sObject を含めるよう CRM Analytics に指示する、HasCases
という定数を追加します。
では、CRM Analytics はこの変数をどこで探すのでしょうか? おわかりのとおり、variables.json
です。したがって、SObjectChoices 変数を追加します。
ウィザードの質問の「Choose additional objects to include in your app」 (アプリケーションに追加するオブジェクトを選択してください) というテキストが表示されます。また、“itemsType”
の下に “Cases” enum として表示されます。
最後に、以下は、新しい SObjectChoices
変数を参照する質問を表示するようウィザードに指示する、ui.json
の JSON です。
前述のとおり、元の ui.json
ファイルは空でした。
ウィザードの誕生
これで終わりです。新しい JSON によってテンプレートにどのようなことが行われるのかを次に示します。
- ケースオブジェクトのデータをアプリケーションに追加したいかどうかをユーザーに尋ねる、1 つの質問が設定されたウィザードを追加します。
- アプリケーションの作成時に新しいケースデータセットを追加するよう CRM Analytics に指示します。
- ケースのデータを使用して Service Performance ダッシュボードを作成するよう CRM Analytics に指示します。
素晴らしいですよね? 短いシンプルなコードから強力な結果が得られます。まだ終わりではありません。CEO から、他にもいくつかのオプションをテンプレートに追加するよう依頼されています。次はその作業を行います。
同じダッシュボード、異なるデータ
DTC の CEO はパートナーから、Execs Only ダッシュボードに新規ビジネスの場所やソースに関するデータを表示する方法を変更できないかと聞かれていました。DTC のバージョンでは、地理データが取引先オブジェクトの [国(請求先)] 項目を基に表示されます。DTC ではこの項目を使用して、顧客の場所を追跡しています。アプリケーションのダッシュボードには、商談オブジェクトの [リードソース] 項目に基づいて新規ビジネスが表示されます。DTC ではこの項目を使用して、担当者が潜在的な新規ビジネスを示しています。
パートナーが Execs Only の各自のバージョンに表示されるデータを管理できるようにするにはどうすればよいでしょうか? ウィザードに質問を追加します。どのように追加するのでしょうか? JSON ファイルを編集します。前のセクションを注意深く読んでいれば、どのファイルを編集するのか明白かもしれません。
-
Template-to-app-rules.json
では、ウィザードで選択した項目のデータを使用してダッシュボードで何を行うかを定義します。
-
variables.json
では、ウィザードの質問を追加して、パートナーが質問に答える場合の選択肢となる値を指定します。
-
ui.json
では、ウィザードに表示する質問の順序を決定します。
ここでは、template-info.json
は変更しません。アプリケーションに要素は追加せず、アプリケーションに含まれるデータの一部を変更するだけだからです。
以下はそのコードです。Template-to-app-rules.json
には他にも空の rules
セクションがあったことを覚えていますか? ダッシュボードに表示する具体的なデータに関する質問を追加するために、ここでは 2 つのルールをこのセクションに追加します。以下は、ReplaceDashboardVariables
という 1 つ目のルールのファイルの冒頭です。
ReplaceDashboardVariables
ルールは、ユーザーがウィザードから [Lead Source (リードソース)] 以外の値を選択した場合に、ダッシュボードのデフォルトのディメンションの表示ラベルと名前を置換します。ルールは、いくつかの set アクションを定義します。この場合は、アクションがダッシュボードの値を設定します。アクション 1 は、新規ビジネスのソースを示す目的でパートナーが選択する項目名 (fieldName
) を設定します。Execs Only では、これらの値は [Word of mouth (クチコミ)] や [Public Relations (広報)] など、[Lead Source (リードソース)] 項目の選択肢になります。アクション 2 は、この項目 (fieldLabel
) からのデータを含む検索条件の表示ラベルを設定します。
以下は、Pipeline Performance ダッシュボードの [リードソース] グラフです。[Lead Source (リードソース)] という表示ラベル (1) と、[Lead Source (リードソース)] 項目の選択肢 (2) が示されています。パートナーは、新規ビジネスのソースとして、別の項目の使用を選択できることを望んでいます。パートナーが選択した [New Business (新規ビジネス)] という項目が [リードソース] と置換され、[New Business (新規ビジネス)] 項目の値が [Employee Ref (従業員の紹介)]、[Public Relations (広報)] などに置換されます。
アクション 3 と 4 は、地理データに対して同じことを行います。Execs Only では [Billing Country (国(請求先))] 項目の選択肢がカナダ、米国などの国名で、表示ラベルは [Billing Country (国(請求先))] です。
以下は、ReplaceWorkflowVariables
という 2 つ目のルールで、データフローファイルに適用されます。(Workflow は、アプリケーションのデータフローのことです)。アクション 5 は、データフローの新規ビジネスのソースデータを置換します。アクション 6 は地理データに対して同じことを行います。
新しいアクションはすべて、variables.json
で定義されている変数 (Variables.Geography.fieldName
など) をポイントします。
変数 1 は、地理データに関するウィザードの質問と、パートナーが答えを選択する場合に役立つ説明の両方を定義しています。また、どの sObject
に、パートナーの組織の値 (ウィザードで有効な答えとなるもの) を含めるかを指定します。テンプレートではこの答えを使用して、カスタマイズされたダッシュボードエクスペリエンスを創出します。変数 2 は、新しいビジネスのソースに関するウィザードの質問について同じことを行います。変数 3 は元の上書きで、すでに説明しました。
最後に、以下は新しいウィザードの質問の順序を決定する ui.json
のコードです。Execs Only アプリケーションへのケースの追加に関する質問も含まれています (SObjectChoices
)。
ウィザードのさらなる効率化
では、これまでに追加した JSON によってテンプレートがどのようになるのか見てみましょう。
- いくつかの質問が追加され、ウィザードが「さらにスマート」になります。ユーザーはこの時点で、ケースデータに関する質問のほか、場所や新規ビジネスのソースに関する質問にも答えることができます。
- ユーザーが、場所の区分や新規ビジネスのソースの追跡に使用する項目を選択できるようになります。
- データがダッシュボードやデータセットの適切な場所に表示されるようになります。
短い JSON コードのお陰で、パートナーがテンプレートでアプリケーションの作成方法について選択を行えるようになります。また、Service Performance ダッシュボードを追加して、アプリケーションのダッシュボードに各自のデータの保存方法 (や希望する表示方法) が反映されることを確認できます。
あなたは CEO に見せたくてワクワクしています。きっと CEO も喜んでくれるはずです。ところが、JSON で作業するうちに、CEO、そしてパートナーをいたく感動させると思われるアイデアがいくつか浮かんでいました。CEO に話をしに行く前に、こうしたアイデアを試してみることにします。
テンプレートをさらに強化する前に、後続の質問に答えて「CRM Analytics テンプレート」バッジの獲得を目指しましょう。