全く使ってないこともあって、何にも理解してない機能の代表です。
まぁ、理解してないから使えないってことですけどね。
そもそも何に使うの？
Salesforceのすべてのレコードには所有者が必要です。
所有者は単一のエンティティであり、キューを使用すると、特定のオブジェクトでユーザーのグループにレコードを所有させることができます。
それじゃあ、ユーザのグループに割り当てたらいいじゃんと思う。
キューは、チームがリード、ケース、サービス契約、およびカスタムオブジェクトを管理するのに役立ちます。
レコードが手動で、または自動ケースまたはリード割り当てルールを介してキューに配置されると、
レコードは、ユーザーに割り当てられるか、キューメンバーの1人によって取得されるまでそこに残ります。
キューメンバーまたはその上位のロール階層のユーザーは、キュー内のレコードの所有権を取得できます。
あんまり便利に感じない。
キューを設定して、公開グループを所有者にしてみてください。
Salesforce のキューはユーザー レコードのように機能します。ユーザーがレコードの所有者になるのではなく、キューがレコードの所有者になり、レコードは誰かが作業するのを保留しています。
どんな種類があるんだろう。
リードキュー
リードの配布を管理するのに役立ちます。たとえば、西部地域のチームと東部地域のチームのリードキューがあるとします。リードは手動でインポート、作成、編集されるか、Webからキャプチャされるため、リードを手動で、またはリード割り当てルールを介して自動的に、さまざまなキューに入れることができます。営業担当者を1つ以上のリードキューのメンバーにします。
ナレッジ記事のバージョンキュー
翻訳用のSalesforceナレッジ記事のバージョンの配布を管理するのに役立ちます。たとえば、ナレッジベースに複数の言語が使用されている場合、記事を特定の言語に翻訳できるユーザーのキューに新しいバージョンの記事を割り当てることができます。
サービス契約キュー
サービス契約の配布を管理するのに役立ちます。たとえば、サービス契約を確認する専用のユーザーグループがあるとします。サービスコントラクトが作成されたら、それをキューに割り当てて、キューメンバーがサービスコントラクトを確認できるようにします。
カスタムオブジェクトキュー
カスタムオブジェクトレコードの配布を管理するのに役立ちます。カスタムオブジェクトレコードが作成されたら、キューに割り当てられたユーザーがアクセスして所有権を取得できるように、手動でキューに割り当てます。
Salesforce キューについて知っておくべきことの翻訳
Everything You Need to Know About Salesforce Queues
Salesforce キューは、ワークロードを共有するチームが使用するレコードに優先順位を付け、配布し、割り当てます。ケース、リード、タスク、連絡要求、注文、サービス契約、ナレッジ記事、およびカスタム オブジェクトを管理するには、Salesforce のキューを使用します。
Salesforce キューとは?
Salesforce キューは、ワークロードを共有するチームが使用するレコードに優先順位を付け、配布し、割り当てます。キューは、CRM の保持領域のように機能し、レコードが誰かが取得するのを待ち、レコードの所有者を自分自身または別のユーザーとして割り当てます。
- 特にすべてのユーザーの容量が変動する場合に、共有ワークロードの管理を容易にします。
- 何をする必要があるかを可視化します。つまり、すべてのキュー メンバーに通知するのに便利な方法です。これは、チーム メンバーが病気の場合や休暇中の場合に特に役立ちます。
キューは Salesforce でどのように機能しますか?
Salesforce のキューはユーザー レコードのように機能します。ユーザーがレコードの所有者になるのではなく、キューがレコードの所有者になり、レコードは誰かが作業するのを保留しています。
Salesforce キューを構成する複数の部分があります。
- キュー メンバー
- メールをキューに入れる (オプション)
- 割り当てルールを記録する
- クイックアクション
キューに参加できるのは誰ですか? (キューメンバー)
管理者はユーザーを Salesforce キューに追加できます。これらはキュー メンバーと呼ばれます。キューのメンバーは、キューが所有するレコードを受け入れることができます (ロール階層の上位のユーザーも、キュー内のレコードの所有権を取得できることに注意してください)。
キュー メンバーは、次の方法で追加できます。
- 個々のユーザー (1 人ずつ)
- 役割、役割と部下 (一度に複数のユーザー)
- 公開グループ (一度に複数のユーザー)
レコードをキューに追加するにはどうすればよいですか? （記録譲渡規則）
キューはレコード所有者と同じ特性を共有します。したがって、キューにレコードを追加するには、レコード所有者を更新するだけで済みます! これには 2 つの方法があります。
- 自動: 「割り当てルール」は、特定のレコード基準に基づいて、作成時にレコードをキューに追加します。たとえば、リード割り当てルールは、フランスからのリードを「新しいリード – フランス」キューに追加し、ドイツからのリードを別のユーザー/キューに追加できます。
- 手動: レコード ページから、レコード所有者を更新してキューにすることができます。たとえば、リードの「リード所有者」を「新しいリード – フランス」キューに変更します。
Salesforce のキューとグループ
Salesforce のキューとグループの違いは何ですか? キューはユーザーのグループとして説明されるため、「グループ」と混同される可能性があります。これは、Salesforce でレコードを共有する別の方法です。
- 公開グループは、Salesforce で最も広く使用されているタイプのグループです (その他のあまり一般的でないグループは、個人グループとマネージャ グループです)。
- 公開グループ (最も一般的) は、Salesforce 管理者によって作成されます。これらには、個々のユーザー、他のグループ、または特定の役割または地域のユーザーを含めることができます。グループを使用すると、レコードの可視性を一度に複数のユーザーに拡張できます。これらのレコードのレコード所有者をユーザーが変更することはできません*が、キューは変更できます。
- 公開グループのキュー メンバーシップをベースにすることができます (つまり、公開グループのすべてのユーザーは、レコードを表示し、レコードの所有者を変更することができます。
エンタープライズテリトリー管理が有効になっている場合。
*グループ内のユーザーは、ロール階層または共有ルールを介して付与された、プロファイル(または権限セット) と「レコードの転送」および編集アクセス の組み合わせにより、レコード所有者を変更する権限を持つことができます。
その他の Salesforce キューの例
Salesforce のキューを使用して、ケース、リード、タスク、連絡要求、注文、サービス契約、ナレッジ記事、およびカスタム オブジェクトを管理できます。
組織内のより多くのチームにキューの素晴らしさを拡張する方法の例を次に示します。
- ケースの場合: サービス エージェント用に「優先度の高いケース」キューを作成します。
- カスタム オブジェクトの場合: たとえば、特定のスキル セットを必要とする「新しいプロジェクト」。
- タスクの場合: 通話タスクの「ウェビナー フォローアップ」キュー。
Salesforce で使用できるキューの数は?
朗報です。キューはいくつでも作成できます。ユーザーを過負荷にしないでください。結局のところ、これを、作業を開始するレコードをピックアップするための「頼りになる」リストの 1 つにしたいのです。スピード、効率、コラボレーション…すべてが優れています!
概要
簡単に言えば、Salesforce キューを使用すると、ユーザーはレコードに優先順位を付け、配布し、割り当てることができます。これは、ワークロードを共有するチームに最適です。キューはユーザーのグループをまとめて、共有ワークロードの管理を支援すると同時に、何をする必要があるかについての可視性を高めます (チーム メンバーが病気や休暇中であっても)。
キューはスマートな作業方法です。そのため、キューを組織内の他のチームに拡張する方法を検討してください。結局のところ、必要な数だけキューを作成できます。
キューが作成できない条件
Which [types of] objects can have Approval Requests assigned to a Queue?
キューへの承認ステップの割り当て
関連付けられたオブジェクトがキューをサポートしている場合にのみ、承認申請をキューに割り当てることができます。 電子メール承認応答は、承認をキューに割り当てる承認プロセスではサポートされていません。
太字のところは具体的に何よ？何ができないのか？
ここに出てこない
カスタムオブジェクトは別のオブジェクトと主従関係を持っていますか? 論理的には、オブジェクトが別のオブジェクトの子である場合、それはそれ以上のものを持つことができないため、キューを持つこともできません。
数式
here is not "New" button to select in Queues
I think this might any issue with your trailhead playground. Unfortunately, you might need to try it in a different playground
フローで使う
- Make sure the queue has access to the custom object
- In your flow, set the OwnerId of the record = [Your QueueId]
If you're deploying your Queue in Production and testing this out in Sandbox, be mindful that the QueueIds will be different between those orgs. To avoid running into an issue like this, you can Dynamically get the QueueId using a Get Record element in your flow. Here is a helpful resource on how to accomplish this: https://salesforce.stackexchange.com/questions/290038/flow-builder-dynamically-get-queue-id-by-name
承認プロセスで使う
サービス セットアップでは表示されない
