Financial Services Cloud Agents: Meeting Concierge — Pre-Meeting Preparation
Introduction
In the previous article we learnt about the architecture and data model of the meeting concierge agent. In this article we will focus on the set up and configuration of the agent. By the end of this article we should be able to understand the set up, configure it to match our requirements and also make it work! Just like all admin configuration starts at ‘Quick Find’, meeting concierge can also be configured here.
Setup and Configure
To start the setup — Let’s go to ‘Setup’ under the gear icon and search for ‘Agentforce Meeting Concierge’ in ‘Quick Find’. Select the displayed option under ‘Feature Settings’ as shown in the screenshot below.
Creating a playbook definition record like the Annual Review as shown above is required to structure the display of the components in the agent.
Meeting Playbook Definition is an object behind the scenes which persists the type of the meeting and the details required to be captured.
Querying the MeetingPlaybookDefinition object record displays the below details. It is interesting to note that the Meeting Concierge objects can only be queried from ‘Developer Console’ (Web Console was not enabled). I get an ‘Invalid SObject’ error while using the same query in the ‘Salesforce Inspector Reloaded’ tool as shown in the screenshot below. We are very much accustomed to using the inspector tool, it is strange why these objects are unavailable here. [This is the first time I have seen an object not accessible in inspector even after enabling the Tooling API but accessible via Developer Console. Please leave a comment if you know the reason behind this behaviour.]
Also, this object is not available under object manager as shown below. So it is very much safe to say, the Salesforce team planned to use it as a behind the scenes object and expose it may be in the near future (Forward Looking Statement!) when complex requirements arise.
Why is it necessary to understand an object, which is neither visible nor editable, you may ask? As the cliche goes ‘The devil lies in the details’ and understanding the foundation/data model of the application gives us the power to utilize it to the fullest extent possible (It also makes me feel like 007 🙂).
Get Sneha Kashyap’s stories in your inbox
Join Medium for free to get updates from this writer.
For example when I try to create a new playbook from scratch. (I clicked the ‘New Playbook’ button and selected ‘Create From Scratch’). Every meeting playbook definition requires us to configure the details for all the phases of the meeting — Pre-meeting, In-Session and Post-Meeting. The advantage of having different playbook definitions is the fact that the underlying prompts and flows can be modified to match the meeting type.
We can configure the flows and prompts as shown below. Each section provides an option to create and customize a prompt template, which can call a flow to ground the data.
Each of the sections displayed in the screenshot above can be configured.
Client Summary — Provides the summary of the client information. The summary is grounded using the data from Account, Contact, Individual, Household accounts. The data is retrieved via a complex pre-designed flow provided by Salesforce. We customized it to retrieve data from Account and Contacts. Our customer data lies in only those two objects. Remember to customize the flow based on the internal object model.
Meeting Prep Tasks — Meeting prep tasks provides an option to select the predefined action plan template. The action plan template defines the list of sub tasks required to complete the parent task. For Example — Before meeting the client, I have to check the past actions, meetings etc. A list of such standard tasks can be grouped under an action plan template and referenced here to create the tasks in the system.
Documents — Interestingly documents provide the edge and a unique perspective to the entire meeting preparation process. It allows the user to incorporate the data external to Salesforce (outside Accounts, Contacts). Any image, PDF document capturing information about the client can be uploaded to see the Client summary and meeting prep brief sections updated to include the new information.
This, I feel, is like a double edged sword, while the documents do provide the necessary information, we need to be mindful of the number of documents uploaded and the storage it consumes. Ideally defining an archival policy for these documents at the start of the project avoids the data/file storage surprises.
Meeting Prep Brief — As the name suggests, this section prepares the brief of what was discussed in the past, what is the portfolio of the customer (Think Net worth, Financial Accounts), what has changed after the last meeting (Think Life Events), Pending action items and suggested discussion points. This section’s data is grounded using the pre-defined huge (monster) flow.
This flow caters to all the necessary objects ever required/used in the entire customer lifecycle in the Financial Services Industry.
Clone the flow, customize it to your business requirements either by removing or modifying the flow elements. The grounded data then displays necessary information and executes faster.
Attendees — This provides details of the meeting attendees, either contacts, leads, person accounts or internal users.
With the basic set up and understanding of the pre-meeting section of the agent, let us learn more about the ‘In Meeting Facilitation’ and the ‘Post Meeting Follow-up’ sections in the upcoming article.
Conclusion
I never anticipated this to become a multi-article series, but as I dug deeper into the data model, set up and the configuration, logically breaking it into multiple articles made sense.
This does not complete the article about Meeting Concierge Agents, but provides a foundation and in-depth understanding of the working of the OOTB agent.
This disproves my theory of if Salesforce provides everything OOTB then we as developers and architects would not have anything to do! We shoulder a larger responsibility of understanding the heavy-lifting done by Salesforce and making the best use of it to reduce the Total Cost of Ownership and Time to Market the application.
