3

さて、銀行に信頼性の低いスタッフでいっぱいのコールセンターがあると想像してみてください。スタッフは電話で顧客に基本的なサービスを提供する必要があります。コールセンターのスタッフは、顧客からの電話を受け、特定のセキュリティの質問をしてから、何らかの方法でアカウントにサービスを提供します。

現在、顧客の観点から、銀行はセキュリティの質問をすることによって彼らが誰であるかを確認しています。これは銀行の観点とは微妙に異なります。それは、コールセンターの従業員が顧客と話していることを確認することです。

この違いが重要なのはなぜですか？銀行はこれらの信頼性の低いスタッフを制限したいので、顧客が電話をかけるまでアカウントの詳細を表示できません。そのため、コールセンターの従業員は、自分に連絡してサービスを依頼しただけではない顧客のアカウントの詳細を閲覧することはできません。

したがって、問題は次のとおりです。この種のセットアップはDynamics CRM 2011で可能ですか？どのようにそれを実装するのでしょうか？ある程度のカスタマイズは問題ありませんが、CRMデータから駆動される特注のアプリケーションは問題ありません。

いくつかのセキュリティの質問に答えた後、レコード（およびそのすべての子）に対するユーザーのアクセス許可を一時的に変更するカスタムコンポーネントを作成できる可能性があると思います。ただし、CRMで（所有権を超えた）レコードベースのセキュリティがサポートされているかどうかさえわかりません...？一時的にユーザーに所有権を割り当てることができると思います。それは賢明ですか？

注意： GUIからビューを非表示にしてボタンを検索するだけでは、ここで求めているセキュリティレベルではありません。私たちは、ユーザーが問題のレコードにアクセスすることを文字通り制限しようとしています。

4

3 に答える 3

1

免責事項：この回答は、CRM4.0の豊富な経験と2011年のリリースノートを読んだことに基づいています。

簡単な答え：いいえ。

長い答え：はい、しかしカスタマイズは重要です。頭に浮かぶ「最も簡単な」オプションは、認証プロセスが、a）サービスアカウントを使用してエンティティを個人に再割り当てし、関連するCRMに返すオーダーメイドのasp.netページとして実行されることです。フォームを作成し、変更の保存時に再割り当てするプラグイン、またはb）サービスアカウントとして情報を更新および取得するための独自のフォームセットを用意し、セキュリティの質問に回答した後にのみ実行します。

余談ですが、CRM 4.0では、あらゆる種類の「スクリプト化された」形式はほとんど不可能です。2011年はそれを少し改善したと思いますが、私が見たものはまだ勇気づけられていません。コンタクトセンターでCRMを使用するということは、サードパーティのフォーム作成ソフトウェアに投資し、CRMから起動して、Webサービス（非常に柔軟）を介してデータを返すことができるオーダーメイドのフォームを作成することを意味します。CRMインターフェースは、過去のリクエストを表示するためにのみ使用します。ほとんどの更新でさえ、特注のフォームの1つをトリガーします。

于 2011-06-16T15:08:45.683 に答える
1

私はいくつかのオプションを見ることができます：

  1. 権限モデル内での作業。これはうまくいくかもしれません。デフォルトでアクセスを制限し、アカウントの詳細を入力する別のエンティティを作成すると、プラグインが実行されて詳細が確認され、現在のユーザーとレコードが共有されます。ただし、共有解除がどのように機能するかについては少し心配です。何がそれを引き起こしますか？CRMの外部で実行され、定期的にレコードの共有を解除するプロセスはありますか？そのプロセスが失敗した場合はどうなりますか？このタイプのモデルでは、過去にパフォーマンスの問題も発生しました... CRMは、個々のレコードの権限がこのように変更されるたびに、内部で多くの作業を行うようです。
  2. あなたが提案するように、所有者を再割り当てします。複数のユーザーが同じデータを見る必要がありますか？レコードの所有者は、他の理由で維持する必要がありますか（たとえば、これはジョーが所有者であるため、これはジョーのアカウントです）。
  3. プラグインのみを使用します。レコードのRetrieveおよびRetrieveMultipleにプラグインを登録することができます。このプラグインは、エンドユーザーから隠したいすべての詳細を除外することができます。ユーザーが残りのデータを表示する必要がある場合は、フォームやダイアログなどにデータを入力します。このデータは、レコードの取得呼び出しに含まれます。プラグインは非表示のデータをチェックし、そこにあることと正しいことを確認してから、それを取り除き、リクエストを続行できるようにします。今回のみ、すべての属性を取得し、フォームに期待どおりに入力されます。
于 2011-06-16T15:11:34.643 に答える
1

このようなシナリオを実装する場合は、顧客レコード（new_customer）にリンクされた顧客アクセスレコード（new_custaccess）を作成します。この例では、単純に保つために、銀行員（オペレーター）がレコードにアクセスする前に、顧客が提供する必要のある単純なアクセスコードを持っていると想定します。アクセスコードは、フィールド（new_secretcode）のnew_custaccessに保存されます。

セキュリティは、オペレーターがnew_customerに対する特権と、new_custaccessに対する読み取り/更新特権を持たないことです。

new_custaccessには、オペレーターが更新できる単一のフィールド（new_secretcodeoperator）があります。他のすべてのフィールドは、オペレーターへの更新（および適切な場合は読み取り）が制限されています。

顧客が電話をかけ、オペレーターが適切なnew_custaccessレコードを検索したとき。レコードを見つけたら、顧客が提供したシークレットコードをフィールドnew_secretcodeに入力し、保存します。

更新前のクエリは、完全な権限を持つユーザーのコンテキストでnew_custaccessに対して実行されます（ここでは、楽しみのためにMASTERと呼びます）。このプラグインは、提供されたコードがシークレットコードと一致するかどうかを確認します。そうでない場合はエラーがスローされ、オペレーターは再試行できます。プラグインが一致する場合は、フィールドnew_secretcodeoperatorをレコードから削除して、値が保存されないようにします。また、レコードnew_customerに対する適切な権限を適切なオペレーターと共有します。

これで、オペレーターは顧客レコードにアクセスできるようになります（アクセス許可をカスケードするか、各レコードで共有するかを決定する必要があります。その決定は、この説明を超えています）。

ここで、顧客レコードの許可の取り消しに対処する必要があります。これを処理するには、Customerレコードへのアクセスが許可されるたびに、前のプラグインによって生成されるエンティティnew_customeraccessを作成します。new_customeraccessの作成時にワークフローをトリガーして、new_customeraccessを20分ごと（またはクライアントが希望する時間）に更新する必要があります。

プラグインは、ワークフローによって更新されたフィールドが変更されたときに起動するnew_customeraccessの更新に登録されます。このプラグインは、ビジネスによって決定された基準を介して、共有を続行するか、共有を取り消すかを決定します。

また、new_customerリボンからjavascript / htmlベースのポップアップを作成して、new_customeraccessのフィールドを更新して共有を終了します。フィールドレベルのセキュリティを介して、new_customeraccessの限定された更新特権をオペレーターに提供します。

これにより、標準のCRMカスタマイズモデルの外に出ることなく、目的を達成できるはずです。オーダーメイドでどこに線を引くかは正確にはわかりませんが、これはおそらくOOTBに到達するのと同じくらい近いでしょう。いくつかのプラグインは、必要なすべてのC＃です。そして、JavaScriptは機能性ではなく、使いやすさのためだけのものになります。

ご不明な点がございましたら、お気軽にお問い合わせください。

于 2012-11-30T05:28:13.803 に答える