Tightly Binding Agent Co-Pilot Summaries to the Correct D365 Member Account

Introduction

Genesys Cloud's Agent Co-Pilot can automatically generate a summary of each customer interaction, which is extremely useful for after-call work. However, when integrating with Microsoft Dynamics 365 (D365), it's critical to ensure these AI-generated summaries are only pushed to the correct member's account record. If a summary is attached to the wrong account, it can lead to serious data integrity and privacy issues (often called cross-account contamination). The goal is to tightly bind the Co-Pilot summarization lifecycle – from start through push – to the active D365 customer context. In practice, this means the Co-Pilot summary process must be context-aware and only operate when an agent has a confirmed D365 member record open for the interaction. Genesys Cloud does support querying and exporting conversation summaries via API for CRM integration[1], but it's up to administrators and developers to implement the proper safeguards so summaries go to the right place. Below we outline the functional requirements and best practices for achieving this binding.

Key Functional Requirements

To guarantee that Co-Pilot summaries are linked to the correct Dynamics account, the following requirements must be met:

·       Context before Summarization: Summarization must not begin until a Dynamics 365 member account record is actively open/identified. In other words, Co-Pilot's auto-summary should only activate after the agent is viewing a confirmed customer record in D365. If an interaction isn't yet tied to a CRM contact/lead/account, the summarization feature should remain idle (or in a paused state).

·       No Context = No Summaries: If no D365 member record is open, Co-Pilot should not generate or display a summary. The system should effectively prevent or delay any auto-summarization when the CRM context is missing. This ensures you don't produce a summary that might accidentally be saved to the wrong place or require manual handling.

·       Validated Member for Push: When the call ends, push the summary to D365 only if a valid, active member record has been confirmed for that interaction. The integration must double-check that the conversation is associated with a specific Dynamics contact/account before transferring the summary text. If the CRM context was never set (or was lost), the summary should not be auto-sent into D365.

·       Reset on Session Change: If the agent closes the current member's session or switches to a different account record mid-interaction, the summarization process should reset. Any ongoing or pending summarization tied to the previous context should be cleared or halted to avoid mixing content between accounts. Essentially, Co-Pilot's summary lifecycle should be tightly scoped to one CRM session – when the agent moves to another customer or a new session, it should treat it as a fresh start.

·       Explicit Lifecycle Controls: Provide clear controls or hooks for "start, stop, push, reset" that are triggered by D365 context events. In practice, this means your integration or custom code should listen for events like record opened, record closed, record changed, and invoke the appropriate summarization control:

·       Start when a D365 member context is established (e.g. agent has an active contact open).

·       Stop/Pause if the context is removed or unknown (e.g. agent navigates away or no contact selected).

·       Push when ready to send the final summary to CRM (e.g. on call completion, if context is valid).

·       Reset when the session ends or the agent switches context (clearing any state so the next interaction starts cleanly).

These requirements enforce that an Agent Co-Pilot summary is always explicitly linked to a single, correct Dynamics 365 member record throughout its creation and delivery.

Implementing a Context-Bound Summarization Lifecycle

Meeting the above requirements involves configuring the Genesys–D365 integration and possibly adding custom logic. Below are best practices and implementation guidelines to tightly bind the summarization lifecycle to the CRM context:

• 1. Establish CRM Context Before Summarization: Leverage Genesys Cloud's integration (InteractionSync for D365) to identify and lock in the customer context at the start of the call. InteractionSync will typically do an automated screen-pop in Dynamics, searching for the incoming caller's record and opening it for the agent[2]. It also automatically creates a Dynamics activity (e.g. Phone Call record) for the interaction and associates it to the found contact/lead/account[2]. This means as soon as the call begins (and the caller is identified), there is a specific CRM record tied to the interaction. Ensure this screen-pop and activity creation is working reliably for your queues (configure the integration's lookup logic so that it finds the correct member by phone number or other identifiers). If the integration cannot find a match and the agent must search manually, make it a standard operating procedure that the agent selects or creates the correct member record before proceeding further. In summary: do not let the call progress to wrap-up or summary generation without an attached CRM context. This is the foundation – the Co-Pilot summary feature needs that "anchor" to a Dynamics record.
• 2. Gating Auto-Summarization on Context: Out-of-the-box, Agent Co-Pilot will generate a summary when an interaction is completed (disconnected) as long as the feature is enabled for that interaction type[3][4]. You can't truly "stop" Co-Pilot from attempting to summarize a conversation it handled – but you can gate whether that summary gets used or pushed to CRM. One strategy is to configure Co-Pilot or your business rules such that summarization is expected only in certain scenarios (for example, enable Co-Pilot on queues or interactions that are likely to have an identified customer). If an interaction ends and no Dynamics record was ever opened (meaning the call remained anonymous), simply do not transfer the summary anywhere. It will exist in Genesys for a brief period (by design, Co-Pilot summaries are stored for 10 days internally[5]), but your integration should treat it as a no-op in terms of CRM. In effect, Co-Pilot is "paused" waiting for a valid customer context. As soon as the agent does identify/open a member record (even if mid-call), that event can serve as the green light to resume or consider summarization active. If your integration is capable, you might even programmatically trigger the summary generation at that moment (e.g. by calling the summarization API at call end, once context is confirmed). The key is that no summary leaves Genesys Cloud unless a member context is set.
• 3. Hooking into Context Changes (Start/Stop): It's important to tie into the events of your CRM UI so you know when an agent has opened or closed a member's record. In Dynamics 365 (especially with the multi-session interface for Customer Service), each session/tab corresponds to a customer issue or account context. The Genesys integration can be extended via the Dynamics Channel Integration Framework (CIF) or client-side scripts to detect when a new session starts or ends. For example:

·       When a screen pop occurs and opens a contact, have that trigger a "Start Summarization" event in your logic. This could be as simple as setting a flag in the Genesys conversation's participant data that "CRM Context = [ContactID] established", or enabling a timer/collection of transcript for summary. From this point, Co-Pilot can continue transcribing and later summarizing, confident there's an associated account.

·       If the agent closes the contact tab or Dynamics session before the call is over (intentionally or accidentally), catch that event to "Pause Summarization." In practice, you might set a flag like "context lost" which tells your post-call routine not to push any summary. You could even alert the agent or require them to re-open the member record. This prevents a scenario where a summary is generated with nowhere in CRM to go.

·       If the agent switches to a different account record during the call (for instance, they realized the initial screen-pop was the wrong John Smith and they pulled up a different John Smith's record), then you should treat that similar to closing one context and starting another. In other words, reset the summarization binding – mark the old context as inactive and the new one as the official context. Technically, the conversation's transcript is continuous, but by resetting and re-binding to the new record, you ensure the final summary will be linked to the correct customer. (If your integration created an activity on the first record, you may need to update it or create a new one on the correct record – the Dynamics "regarding" field of the Phone Call can be changed to the new contact if needed so that all notes and the summary ultimately relate to the right person.)

• Some Genesys–CRM integrations also support an "Associations" feature in the agent's call log, which allows manually re-linking an interaction to a different CRM entity if needed. If your agents use that, tie your summarization logic to the final association they set. Essentially, always refer to the current associated member record when deciding where to send the summary.
• 4. Pushing the Summary to D365 (Finalize on Call End): The actual handoff of the summary to Dynamics should occur at the end of the call, during the after-call work (ACW) phase or immediately after. This is when Genesys Co-Pilot presents the generated summary to the agent in the interface[3]. At this point, your integration or custom process should do a final check: "Do we have a valid Dynamics member ID for this conversation?" If yes, proceed to push; if not, skip it. Pushing the summary can be accomplished in a couple of ways:

·       Manual method: The agent can copy the Co-Pilot summary text from Genesys and paste it into the call notes or a custom field in the Genesys sidebar, which will sync to the Dynamics activity. (As of mid-2024, this was the primary method – Genesys confirmed that Co-Pilot summarization for D365 requires a manual copy/paste into the wrap-up notes field[6].) While this works, it relies on agent diligence and is prone to error if the agent has the wrong record open. You should train agents to double-check the CRM tab before pasting the summary.

·       Automated method: A more robust approach is to use Genesys Cloud's APIs and Data Actions to transfer the summary directly. Genesys provides a Conversation Summaries API which allows you to retrieve the AI-generated summary programmatically[1]. Your integration can call GET /api/v2/conversations/{conversationId}/summaries (with appropriate authorization) once the call is complete to obtain the summary text and any AI-suggested fields (like reason or resolution). Then, using a Genesys Data Action or a custom service, push that summary into Dynamics. For example, you could update the Phone Call activity's description or add a note to the contact's timeline with the summary text. This automation eliminates copy/paste mistakes. Important: Do this only if conversationId is reliably tied to a Dynamics record. You might use a custom conversation attribute or the activity's CRM ID to correlate – for instance, InteractionSync can store Genesys Conversation ID on the Dynamics activity record[7][8]. By using such an identifier, your code can ensure it's updating the correct Dynamics record with the summary.

• In either case, make sure the Dynamics record is still active/valid at push time. If the agent had closed the CRM tab or if the integration did not find any contact, your push logic should detect that and refrain from sending. It's better to have a summary stay in Genesys (where it expires in 10 days) than to accidentally attach it to the wrong customer in D365.
• 5. Resetting Between Sessions: Each interaction (call/chat/etc.) should be treated as a separate summarization session tied to its own CRM context. Once an interaction is fully completed and the summary has (or hasn't) been pushed, you should reset any tracking variables or context flags in your integration layer. The next call an agent handles will likely pertain to a different account, so your logic should start fresh (waiting for a new screen-pop and context establishment). Genesys Cloud's Agent Co-Pilot will naturally separate summaries by conversation ID, so there's no data overlap on Genesys' side. Your job is to mirror that separation in the CRM integration. For example, if you were storing the current Dynamics record ID in a variable during the call, clear it out at call end. This prevents any chance that a new call could accidentally reuse a previous call's context. Also ensure the Genesys UI is reset – typically, the integration will open a new Dynamics activity for the next call, but if an agent manually stayed on an old record, be cautious. It is a best practice to navigate away from the last contact's screen after finishing ACW, or let the integration auto-pop the next one, so that the visible CRM context always matches the active interaction. The Genesys InteractionSync release notes even highlight multi-session management considerations (for example, a known issue was that if an agent opened a record via search rather than the screen-pop, a session ID wasn't generated[9], which could complicate context tracking). Being aware of such limitations, make sure to test and enforce context continuity between Genesys and D365 at the start and end of sessions.

By following the above practices, you effectively create a mechanism where Co-Pilot's summarization is contextually aware of the Dynamics 365 member session. The summary generation might be an automated AI feature, but you are wrapping it in rules that tie it to Dynamics' state: it "starts" when a customer is identified, it "stops" if the customer context is lost, it only "pushes" upon a valid conclusion with the correct customer, and it "resets" when moving to a new session.

Avoiding Cross-Account Contamination

A primary risk in any CRM-integrated summarization is that a summary from one customer interaction ends up attached to a different customer's record. Here are some best practices to prevent this "cross-account contamination":

·       Enforce One-Conversation/One-Record Linking: Ensure that each Genesys conversation ID is linked to at most one Dynamics record. If your agent tries to handle multiple accounts in one call (e.g. the caller asks about two different people's info – a rare but possible scenario), do not attempt to use one summary for both. Instead, the agent should split the call or notes accordingly. The integration should log the call under one primary contact or case in Dynamics. By keeping this one-to-one mapping, you eliminate ambiguity about where the summary should go.

·       Don't Share Summary Content Across Accounts: Never copy a summary from one member's activity into another's. If information from a call needs to be noted on two accounts (for instance, a conference call involving two clients), it's better to have the agent write separate notes for the second account manually. The Co-Pilot summary is tailored to the single interaction and should remain attached only to the records that were part of that interaction.

·       Use Unique Identifiers for Verification: As mentioned, leverage identifiers like the Genesys conversation ID or the Dynamics activity ID to track the linkage. Many organizations add a custom field in D365 for "Genesys Conversation ID" and populate it for each call activity[7]. This allows you to later audit where a summary was attached. If you ever see the same conversation ID on two different contact records, that's a red flag.

·       Train Agents on the Integration Workflow: Sometimes contamination happens due to human error – e.g. an agent might forget to switch the CRM record when a caller reveals new information ("Actually, I'm calling about my spouse's account, not mine"). Make sure agents know to update the CRM context ASAP in such cases (perhaps using the "Associations" feature to relink the call if needed). If they do that, your integration logic (start/stop/reset as discussed) should handle the rest – but the agent's awareness is the first line of defense.

·       Handle Multi-Tab Concurrency Carefully: If your agents can have multiple customer sessions open concurrently (for example, handling two chats at once with two different members), verify that the Genesys integration truly sandboxes each session. Co-Pilot should be running separately for each conversation. The risk here is lower because Genesys Cloud will generate two distinct summaries for two distinct interactions, but ensure your UI makes it clear which summary belongs to which session. Dynamics 365's multi-session interface usually keeps activities separated by tabs, and each Genesys interaction is associated with the correct tab when using the official integration. Still, it's wise to test this: have an agent handle two interactions and confirm that each Dynamics activity gets the correct notes and summary.

·       Monitor and Log Summary Pushes: Implement logging around the summary push operation. For example, if using a custom Data Action to send the summary to D365, log the conversation ID, target CRM entity, and timestamp. This way, if anything does go awry, you can trace it. Regularly review a few records to ensure summaries are appearing where they should.

·       Beware of "Stale" CRM Context: A common edge-case: the agent ends a call but leaves the Dynamics tab open on that contact, then later takes a new call and forgets that the old tab is still open. If your integration doesn't automatically pop a new tab (say the new call comes in unknown and doesn't pop), the agent might inadvertently paste a summary into the wrong contact's notes. To mitigate this, configure the integration to either always open a new session for each interaction (preferred), or have agents close out old sessions. Some integrations will auto-focus the relevant tab or update it; ensure that behavior is working. Using the session reset best practice from earlier (clearing context between calls) will help avoid this scenario.

In short, maintaining a strong binding between the conversation and the CRM record throughout the call prevents leakage of data across accounts. Each context change is an opportunity to either reinforce the correct link or to halt summarization until the link is corrected.

Verification and Testing

Implementing these controls is only half the battle – you'll want to rigorously test the summarization lifecycle to be confident it behaves as expected. Here are recommended techniques for verification:

·       Simulate Normal Calls: Place test calls where the caller matches exactly one Dynamics contact (or member account). Ensure the integration screen-pops that contact, the call logs to that contact's record, and when the call ends, the Co-Pilot summary appears only on that contact's timeline or activity. Verify that the summary content in D365 matches what Genesys Co-Pilot displayed. This tests the happy path end-to-end.

·       Test No-Context Scenario: Simulate a call from an unknown number that isn't in D365. The integration likely will not pop a contact (it might open a blank search or "new contact" form). Do not select or create any contact – let the call conclude without an associated record. The expectation: Co-Pilot may still generate a summary in the Genesys UI for the agent's reference, but no summary or call activity should appear in Dynamics. Check that no activity was inadvertently created, or if one was (some systems log the call to a generic record), confirm its notes are empty. Essentially, confirm that your "no context, no push" rule is honored.

·       Test Context Gained Mid-Call: Start a call with no initial CRM match, then during the call have the agent manually find and open the correct member record (perhaps the caller provides an email or account number that allows a manual search). Ensure that once the record is open, the rest of the call is logged under that record. When the call ends, the summary should be pushed to that newly selected record's activity. Check that the summary did attach to it, and nowhere else. This verifies that your late-binding of context still triggers the summary push correctly.

·       Test Context Switch Mid-Call: More complex: use a scenario where the wrong contact pops first. For example, two contacts with the same name and your integration pops the first one. Have the agent realize the mistake and switch to the second contact's record while on the call. After call completion, verify that the summary went to the second (correct) contact's record and that the first contact's record (which was initially opened) does not have any summary or has the activity reassigned. This is a crucial test for the "switch and reset" logic.

·       Concurrent Interactions: If applicable, have an agent handle two interactions concurrently (if your business allows, e.g. a voice call and a chat, or two chats). Confirm that two separate summaries are generated and each is pushed to the appropriate Dynamics record. The agent's interface should clearly separate the two (Dynamics will have two activities in two sessions). This test ensures no overlap in multi-tasking scenarios.

·       Long Calls and Edge Cases: Test a long call (over 30-40 minutes) to ensure summarization still functions (Genesys summarization might not produce output if conversation exceeds certain lengths[10]). Also test calls that transfer between agents: if your workflow involves transfers, ensure that when Agent A transfers to Agent B, the summary of Agent A's portion goes to the correct record and Agent B's summary goes to the correct record. (Out of the box, each agent gets their own summary for their portion[11][12]. In a CRM context, both parts should ideally log to the same customer's history – make sure your integration doesn't open a new contact for the second agent erroneously.)

·       Review Audit Trails: After testing, review the Dynamics records and Genesys conversation details. Check that each Dynamics activity has the right Genesys conversation ID (if you map it) and that it matches the conversation where the summary came from. Utilize Genesys's analytics or quality tools to cross-verify content if needed. Also consider enabling debug logging in InteractionSync (Genesys integration) during testing; it can show events like screen-pop, association changes, etc., which help confirm your "start/stop" hooks fired correctly.

By performing the above tests, you can be confident that Agent Co-Pilot summaries are being handled in a controlled, context-sensitive manner. Any discrepancies found should be addressed by refining the integration logic or user procedure before going live.

Conclusion

In a Genesys Cloud + Microsoft Dynamics 365 environment, tying AI summaries to the correct member account is essential for data accuracy, security, and usefulness. The Genesys Agent Co-Pilot feature is powerful, but without the proper context binding, its summaries could end up in the wrong place or at the wrong time. By enforcing that a valid D365 member session is in place for every summary, and by using lifecycle hooks to start, stop, push, or reset summarization based on CRM context, you create a tight coupling between the conversation and the CRM record. This not only prevents cross-account contamination of notes, but also ensures agents and supervisors can trust the summaries they see in Dynamics.

From a practical standpoint, implement the solution using the tools at your disposal: InteractionSync's screen-pop and activity mapping, Genesys conversation attributes and Summaries API, and Dynamics CIF events or custom scripting. Always fail safe – if something isn't right (no context, or context changed), err on the side of not pushing the summary automatically. It's better to have an agent manually intervene in an edge case than to have a summary attached to the wrong account. Finally, continuously monitor and refine the process. As Genesys and Microsoft update their integrations (for example, adding native support for summary injection in future releases), adapt your strategy to take advantage of those while keeping the fundamental requirement in mind: each summary goes to the one and only correct member record.

By following these best practices, Genesys Cloud administrators and developers can confidently deploy Agent Co-Pilot summarization in tandem with Dynamics 365, knowing that the right information will reach the right customer record every time. Your CRM will remain clean and accurate, and your agents will gain efficiency from AI summaries without introducing risk.

Product Owner Question: Will the new AI Studio be able to meet these requirements

Tightly Binding Agent Co-Pilot Summaries to the Correct D365 Member Account

Introduction

Genesys Cloud's Agent Co-Pilot can automatically generate a summary of each customer interaction, which is extremely useful for after-call work. However, when integrating with Microsoft Dynamics 365 (D365), it's critical to ensure these AI-generated summaries are only pushed to the correct member's account record. If a summary is attached to the wrong account, it can lead to serious data integrity and privacy issues (often called cross-account contamination). The goal is to tightly bind the Co-Pilot summarization lifecycle – from start through push – to the active D365 customer context. In practice, this means the Co-Pilot summary process must be context-aware and only operate when an agent has a confirmed D365 member record open for the interaction. Genesys Cloud does support querying and exporting conversation summaries via API for CRM integration[1], but it's up to administrators and developers to implement the proper safeguards so summaries go to the right place. Below we outline the functional requirements and best practices for achieving this binding.

Key Functional Requirements

To guarantee that Co-Pilot summaries are linked to the correct Dynamics account, the following requirements must be met:

·       Context before Summarization: Summarization must not begin until a Dynamics 365 member account record is actively open/identified. In other words, Co-Pilot's auto-summary should only activate after the agent is viewing a confirmed customer record in D365. If an interaction isn't yet tied to a CRM contact/lead/account, the summarization feature should remain idle (or in a paused state).

·       No Context = No Summaries: If no D365 member record is open, Co-Pilot should not generate or display a summary. The system should effectively prevent or delay any auto-summarization when the CRM context is missing. This ensures you don't produce a summary that might accidentally be saved to the wrong place or require manual handling.

·       Validated Member for Push: When the call ends, push the summary to D365 only if a valid, active member record has been confirmed for that interaction. The integration must double-check that the conversation is associated with a specific Dynamics contact/account before transferring the summary text. If the CRM context was never set (or was lost), the summary should not be auto-sent into D365.

·       Reset on Session Change: If the agent closes the current member's session or switches to a different account record mid-interaction, the summarization process should reset. Any ongoing or pending summarization tied to the previous context should be cleared or halted to avoid mixing content between accounts. Essentially, Co-Pilot's summary lifecycle should be tightly scoped to one CRM session – when the agent moves to another customer or a new session, it should treat it as a fresh start.

·       Explicit Lifecycle Controls: Provide clear controls or hooks for "start, stop, push, reset" that are triggered by D365 context events. In practice, this means your integration or custom code should listen for events like record opened, record closed, record changed, and invoke the appropriate summarization control:

·       Start when a D365 member context is established (e.g. agent has an active contact open).

·       Stop/Pause if the context is removed or unknown (e.g. agent navigates away or no contact selected).

·       Push when ready to send the final summary to CRM (e.g. on call completion, if context is valid).

·       Reset when the session ends or the agent switches context (clearing any state so the next interaction starts cleanly).

These requirements enforce that an Agent Co-Pilot summary is always explicitly linked to a single, correct Dynamics 365 member record throughout its creation and delivery.

Implementing a Context-Bound Summarization Lifecycle

Meeting the above requirements involves configuring the Genesys–D365 integration and possibly adding custom logic. Below are best practices and implementation guidelines to tightly bind the summarization lifecycle to the CRM context:

• 1. Establish CRM Context Before Summarization: Leverage Genesys Cloud's integration (InteractionSync for D365) to identify and lock in the customer context at the start of the call. InteractionSync will typically do an automated screen-pop in Dynamics, searching for the incoming caller's record and opening it for the agent[2]. It also automatically creates a Dynamics activity (e.g. Phone Call record) for the interaction and associates it to the found contact/lead/account[2]. This means as soon as the call begins (and the caller is identified), there is a specific CRM record tied to the interaction. Ensure this screen-pop and activity creation is working reliably for your queues (configure the integration's lookup logic so that it finds the correct member by phone number or other identifiers). If the integration cannot find a match and the agent must search manually, make it a standard operating procedure that the agent selects or creates the correct member record before proceeding further. In summary: do not let the call progress to wrap-up or summary generation without an attached CRM context. This is the foundation – the Co-Pilot summary feature needs that "anchor" to a Dynamics record.
• 2. Gating Auto-Summarization on Context: Out-of-the-box, Agent Co-Pilot will generate a summary when an interaction is completed (disconnected) as long as the feature is enabled for that interaction type[3][4]. You can't truly "stop" Co-Pilot from attempting to summarize a conversation it handled – but you can gate whether that summary gets used or pushed to CRM. One strategy is to configure Co-Pilot or your business rules such that summarization is expected only in certain scenarios (for example, enable Co-Pilot on queues or interactions that are likely to have an identified customer). If an interaction ends and no Dynamics record was ever opened (meaning the call remained anonymous), simply do not transfer the summary anywhere. It will exist in Genesys for a brief period (by design, Co-Pilot summaries are stored for 10 days internally[5]), but your integration should treat it as a no-op in terms of CRM. In effect, Co-Pilot is "paused" waiting for a valid customer context. As soon as the agent does identify/open a member record (even if mid-call), that event can serve as the green light to resume or consider summarization active. If your integration is capable, you might even programmatically trigger the summary generation at that moment (e.g. by calling the summarization API at call end, once context is confirmed). The key is that no summary leaves Genesys Cloud unless a member context is set.
• 3. Hooking into Context Changes (Start/Stop): It's important to tie into the events of your CRM UI so you know when an agent has opened or closed a member's record. In Dynamics 365 (especially with the multi-session interface for Customer Service), each session/tab corresponds to a customer issue or account context. The Genesys integration can be extended via the Dynamics Channel Integration Framework (CIF) or client-side scripts to detect when a new session starts or ends. For example:

·       When a screen pop occurs and opens a contact, have that trigger a "Start Summarization" event in your logic. This could be as simple as setting a flag in the Genesys conversation's participant data that "CRM Context = [ContactID] established", or enabling a timer/collection of transcript for summary. From this point, Co-Pilot can continue transcribing and later summarizing, confident there's an associated account.

·       If the agent closes the contact tab or Dynamics session before the call is over (intentionally or accidentally), catch that event to "Pause Summarization." In practice, you might set a flag like "context lost" which tells your post-call routine not to push any summary. You could even alert the agent or require them to re-open the member record. This prevents a scenario where a summary is generated with nowhere in CRM to go.

·       If the agent switches to a different account record during the call (for instance, they realized the initial screen-pop was the wrong John Smith and they pulled up a different John Smith's record), then you should treat that similar to closing one context and starting another. In other words, reset the summarization binding – mark the old context as inactive and the new one as the official context. Technically, the conversation's transcript is continuous, but by resetting and re-binding to the new record, you ensure the final summary will be linked to the correct customer. (If your integration created an activity on the first record, you may need to update it or create a new one on the correct record – the Dynamics "regarding" field of the Phone Call can be changed to the new contact if needed so that all notes and the summary ultimately relate to the right person.)

• Some Genesys–CRM integrations also support an "Associations" feature in the agent's call log, which allows manually re-linking an interaction to a different CRM entity if needed. If your agents use that, tie your summarization logic to the final association they set. Essentially, always refer to the current associated member record when deciding where to send the summary.
• 4. Pushing the Summary to D365 (Finalize on Call End): The actual handoff of the summary to Dynamics should occur at the end of the call, during the after-call work (ACW) phase or immediately after. This is when Genesys Co-Pilot presents the generated summary to the agent in the interface[3]. At this point, your integration or custom process should do a final check: "Do we have a valid Dynamics member ID for this conversation?" If yes, proceed to push; if not, skip it. Pushing the summary can be accomplished in a couple of ways:

·       Manual method: The agent can copy the Co-Pilot summary text from Genesys and paste it into the call notes or a custom field in the Genesys sidebar, which will sync to the Dynamics activity. (As of mid-2024, this was the primary method – Genesys confirmed that Co-Pilot summarization for D365 requires a manual copy/paste into the wrap-up notes field[6].) While this works, it relies on agent diligence and is prone to error if the agent has the wrong record open. You should train agents to double-check the CRM tab before pasting the summary.

·       Automated method: A more robust approach is to use Genesys Cloud's APIs and Data Actions to transfer the summary directly. Genesys provides a Conversation Summaries API which allows you to retrieve the AI-generated summary programmatically[1]. Your integration can call GET /api/v2/conversations/{conversationId}/summaries (with appropriate authorization) once the call is complete to obtain the summary text and any AI-suggested fields (like reason or resolution). Then, using a Genesys Data Action or a custom service, push that summary into Dynamics. For example, you could update the Phone Call activity's description or add a note to the contact's timeline with the summary text. This automation eliminates copy/paste mistakes. Important: Do this only if conversationId is reliably tied to a Dynamics record. You might use a custom conversation attribute or the activity's CRM ID to correlate – for instance, InteractionSync can store Genesys Conversation ID on the Dynamics activity record[7][8]. By using such an identifier, your code can ensure it's updating the correct Dynamics record with the summary.

• In either case, make sure the Dynamics record is still active/valid at push time. If the agent had closed the CRM tab or if the integration did not find any contact, your push logic should detect that and refrain from sending. It's better to have a summary stay in Genesys (where it expires in 10 days) than to accidentally attach it to the wrong customer in D365.
• 5. Resetting Between Sessions: Each interaction (call/chat/etc.) should be treated as a separate summarization session tied to its own CRM context. Once an interaction is fully completed and the summary has (or hasn't) been pushed, you should reset any tracking variables or context flags in your integration layer. The next call an agent handles will likely pertain to a different account, so your logic should start fresh (waiting for a new screen-pop and context establishment). Genesys Cloud's Agent Co-Pilot will naturally separate summaries by conversation ID, so there's no data overlap on Genesys' side. Your job is to mirror that separation in the CRM integration. For example, if you were storing the current Dynamics record ID in a variable during the call, clear it out at call end. This prevents any chance that a new call could accidentally reuse a previous call's context. Also ensure the Genesys UI is reset – typically, the integration will open a new Dynamics activity for the next call, but if an agent manually stayed on an old record, be cautious. It is a best practice to navigate away from the last contact's screen after finishing ACW, or let the integration auto-pop the next one, so that the visible CRM context always matches the active interaction. The Genesys InteractionSync release notes even highlight multi-session management considerations (for example, a known issue was that if an agent opened a record via search rather than the screen-pop, a session ID wasn't generated[9], which could complicate context tracking). Being aware of such limitations, make sure to test and enforce context continuity between Genesys and D365 at the start and end of sessions.

By following the above practices, you effectively create a mechanism where Co-Pilot's summarization is contextually aware of the Dynamics 365 member session. The summary generation might be an automated AI feature, but you are wrapping it in rules that tie it to Dynamics' state: it "starts" when a customer is identified, it "stops" if the customer context is lost, it only "pushes" upon a valid conclusion with the correct customer, and it "resets" when moving to a new session.

Avoiding Cross-Account Contamination

A primary risk in any CRM-integrated summarization is that a summary from one customer interaction ends up attached to a different customer's record. Here are some best practices to prevent this "cross-account contamination":

·       Enforce One-Conversation/One-Record Linking: Ensure that each Genesys conversation ID is linked to at most one Dynamics record. If your agent tries to handle multiple accounts in one call (e.g. the caller asks about two different people's info – a rare but possible scenario), do not attempt to use one summary for both. Instead, the agent should split the call or notes accordingly. The integration should log the call under one primary contact or case in Dynamics. By keeping this one-to-one mapping, you eliminate ambiguity about where the summary should go.

·       Don't Share Summary Content Across Accounts: Never copy a summary from one member's activity into another's. If information from a call needs to be noted on two accounts (for instance, a conference call involving two clients), it's better to have the agent write separate notes for the second account manually. The Co-Pilot summary is tailored to the single interaction and should remain attached only to the records that were part of that interaction.

·       Use Unique Identifiers for Verification: As mentioned, leverage identifiers like the Genesys conversation ID or the Dynamics activity ID to track the linkage. Many organizations add a custom field in D365 for "Genesys Conversation ID" and populate it for each call activity[7]. This allows you to later audit where a summary was attached. If you ever see the same conversation ID on two different contact records, that's a red flag.

·       Train Agents on the Integration Workflow: Sometimes contamination happens due to human error – e.g. an agent might forget to switch the CRM record when a caller reveals new information ("Actually, I'm calling about my spouse's account, not mine"). Make sure agents know to update the CRM context ASAP in such cases (perhaps using the "Associations" feature to relink the call if needed). If they do that, your integration logic (start/stop/reset as discussed) should handle the rest – but the agent's awareness is the first line of defense.

·       Handle Multi-Tab Concurrency Carefully: If your agents can have multiple customer sessions open concurrently (for example, handling two chats at once with two different members), verify that the Genesys integration truly sandboxes each session. Co-Pilot should be running separately for each conversation. The risk here is lower because Genesys Cloud will generate two distinct summaries for two distinct interactions, but ensure your UI makes it clear which summary belongs to which session. Dynamics 365's multi-session interface usually keeps activities separated by tabs, and each Genesys interaction is associated with the correct tab when using the official integration. Still, it's wise to test this: have an agent handle two interactions and confirm that each Dynamics activity gets the correct notes and summary.

·       Monitor and Log Summary Pushes: Implement logging around the summary push operation. For example, if using a custom Data Action to send the summary to D365, log the conversation ID, target CRM entity, and timestamp. This way, if anything does go awry, you can trace it. Regularly review a few records to ensure summaries are appearing where they should.

·       Beware of "Stale" CRM Context: A common edge-case: the agent ends a call but leaves the Dynamics tab open on that contact, then later takes a new call and forgets that the old tab is still open. If your integration doesn't automatically pop a new tab (say the new call comes in unknown and doesn't pop), the agent might inadvertently paste a summary into the wrong contact's notes. To mitigate this, configure the integration to either always open a new session for each interaction (preferred), or have agents close out old sessions. Some integrations will auto-focus the relevant tab or update it; ensure that behavior is working. Using the session reset best practice from earlier (clearing context between calls) will help avoid this scenario.

In short, maintaining a strong binding between the conversation and the CRM record throughout the call prevents leakage of data across accounts. Each context change is an opportunity to either reinforce the correct link or to halt summarization until the link is corrected.

Verification and Testing

Implementing these controls is only half the battle – you'll want to rigorously test the summarization lifecycle to be confident it behaves as expected. Here are recommended techniques for verification:

·       Simulate Normal Calls: Place test calls where the caller matches exactly one Dynamics contact (or member account). Ensure the integration screen-pops that contact, the call logs to that contact's record, and when the call ends, the Co-Pilot summary appears only on that contact's timeline or activity. Verify that the summary content in D365 matches what Genesys Co-Pilot displayed. This tests the happy path end-to-end.

·       Test No-Context Scenario: Simulate a call from an unknown number that isn't in D365. The integration likely will not pop a contact (it might open a blank search or "new contact" form). Do not select or create any contact – let the call conclude without an associated record. The expectation: Co-Pilot may still generate a summary in the Genesys UI for the agent's reference, but no summary or call activity should appear in Dynamics. Check that no activity was inadvertently created, or if one was (some systems log the call to a generic record), confirm its notes are empty. Essentially, confirm that your "no context, no push" rule is honored.

·       Test Context Gained Mid-Call: Start a call with no initial CRM match, then during the call have the agent manually find and open the correct member record (perhaps the caller provides an email or account number that allows a manual search). Ensure that once the record is open, the rest of the call is logged under that record. When the call ends, the summary should be pushed to that newly selected record's activity. Check that the summary did attach to it, and nowhere else. This verifies that your late-binding of context still triggers the summary push correctly.

·       Test Context Switch Mid-Call: More complex: use a scenario where the wrong contact pops first. For example, two contacts with the same name and your integration pops the first one. Have the agent realize the mistake and switch to the second contact's record while on the call. After call completion, verify that the summary went to the second (correct) contact's record and that the first contact's record (which was initially opened) does not have any summary or has the activity reassigned. This is a crucial test for the "switch and reset" logic.

·       Concurrent Interactions: If applicable, have an agent handle two interactions concurrently (if your business allows, e.g. a voice call and a chat, or two chats). Confirm that two separate summaries are generated and each is pushed to the appropriate Dynamics record. The agent's interface should clearly separate the two (Dynamics will have two activities in two sessions). This test ensures no overlap in multi-tasking scenarios.

·       Long Calls and Edge Cases: Test a long call (over 30-40 minutes) to ensure summarization still functions (Genesys summarization might not produce output if conversation exceeds certain lengths[10]). Also test calls that transfer between agents: if your workflow involves transfers, ensure that when Agent A transfers to Agent B, the summary of Agent A's portion goes to the correct record and Agent B's summary goes to the correct record. (Out of the box, each agent gets their own summary for their portion[11][12]. In a CRM context, both parts should ideally log to the same customer's history – make sure your integration doesn't open a new contact for the second agent erroneously.)

·       Review Audit Trails: After testing, review the Dynamics records and Genesys conversation details. Check that each Dynamics activity has the right Genesys conversation ID (if you map it) and that it matches the conversation where the summary came from. Utilize Genesys's analytics or quality tools to cross-verify content if needed. Also consider enabling debug logging in InteractionSync (Genesys integration) during testing; it can show events like screen-pop, association changes, etc., which help confirm your "start/stop" hooks fired correctly.

By performing the above tests, you can be confident that Agent Co-Pilot summaries are being handled in a controlled, context-sensitive manner. Any discrepancies found should be addressed by refining the integration logic or user procedure before going live.

Conclusion

In a Genesys Cloud + Microsoft Dynamics 365 environment, tying AI summaries to the correct member account is essential for data accuracy, security, and usefulness. The Genesys Agent Co-Pilot feature is powerful, but without the proper context binding, its summaries could end up in the wrong place or at the wrong time. By enforcing that a valid D365 member session is in place for every summary, and by using lifecycle hooks to start, stop, push, or reset summarization based on CRM context, you create a tight coupling between the conversation and the CRM record. This not only prevents cross-account contamination of notes, but also ensures agents and supervisors can trust the summaries they see in Dynamics.

From a practical standpoint, implement the solution using the tools at your disposal: InteractionSync's screen-pop and activity mapping, Genesys conversation attributes and Summaries API, and Dynamics CIF events or custom scripting. Always fail safe – if something isn't right (no context, or context changed), err on the side of not pushing the summary automatically. It's better to have an agent manually intervene in an edge case than to have a summary attached to the wrong account. Finally, continuously monitor and refine the process. As Genesys and Microsoft update their integrations (for example, adding native support for summary injection in future releases), adapt your strategy to take advantage of those while keeping the fundamental requirement in mind: each summary goes to the one and only correct member record.

By following these best practices, Genesys Cloud administrators and developers can confidently deploy Agent Co-Pilot summarization in tandem with Dynamics 365, knowing that the right information will reach the right customer record every time. Your CRM will remain clean and accurate, and your agents will gain efficiency from AI summaries without introducing risk.

Tightly Binding Agent Co-Pilot Summaries to the Correct D365 Member Account

Introduction

Genesys Cloud's Agent Co-Pilot can automatically generate a summary of each customer interaction, which is extremely useful for after-call work. However, when integrating with Microsoft Dynamics 365 (D365), it's critical to ensure these AI-generated summaries are only pushed to the correct member's account record. If a summary is attached to the wrong account, it can lead to serious data integrity and privacy issues (often called cross-account contamination). The goal is to tightly bind the Co-Pilot summarization lifecycle – from start through push – to the active D365 customer context. In practice, this means the Co-Pilot summary process must be context-aware and only operate when an agent has a confirmed D365 member record open for the interaction. Genesys Cloud does support querying and exporting conversation summaries via API for CRM integration[1], but it's up to administrators and developers to implement the proper safeguards so summaries go to the right place. Below we outline the functional requirements and best practices for achieving this binding.

Key Functional Requirements

To guarantee that Co-Pilot summaries are linked to the correct Dynamics account, the following requirements must be met:

·       Context before Summarization: Summarization must not begin until a Dynamics 365 member account record is actively open/identified. In other words, Co-Pilot's auto-summary should only activate after the agent is viewing a confirmed customer record in D365. If an interaction isn't yet tied to a CRM contact/lead/account, the summarization feature should remain idle (or in a paused state).

·       No Context = No Summaries: If no D365 member record is open, Co-Pilot should not generate or display a summary. The system should effectively prevent or delay any auto-summarization when the CRM context is missing. This ensures you don't produce a summary that might accidentally be saved to the wrong place or require manual handling.

·       Validated Member for Push: When the call ends, push the summary to D365 only if a valid, active member record has been confirmed for that interaction. The integration must double-check that the conversation is associated with a specific Dynamics contact/account before transferring the summary text. If the CRM context was never set (or was lost), the summary should not be auto-sent into D365.

·       Reset on Session Change: If the agent closes the current member's session or switches to a different account record mid-interaction, the summarization process should reset. Any ongoing or pending summarization tied to the previous context should be cleared or halted to avoid mixing content between accounts. Essentially, Co-Pilot's summary lifecycle should be tightly scoped to one CRM session – when the agent moves to another customer or a new session, it should treat it as a fresh start.

·       Explicit Lifecycle Controls: Provide clear controls or hooks for "start, stop, push, reset" that are triggered by D365 context events. In practice, this means your integration or custom code should listen for events like record opened, record closed, record changed, and invoke the appropriate summarization control:

·       Start when a D365 member context is established (e.g. agent has an active contact open).

·       Stop/Pause if the context is removed or unknown (e.g. agent navigates away or no contact selected).

·       Push when ready to send the final summary to CRM (e.g. on call completion, if context is valid).

·       Reset when the session ends or the agent switches context (clearing any state so the next interaction starts cleanly).

These requirements enforce that an Agent Co-Pilot summary is always explicitly linked to a single, correct Dynamics 365 member record throughout its creation and delivery.

Implementing a Context-Bound Summarization Lifecycle

Meeting the above requirements involves configuring the Genesys–D365 integration and possibly adding custom logic. Below are best practices and implementation guidelines to tightly bind the summarization lifecycle to the CRM context:

• 1. Establish CRM Context Before Summarization: Leverage Genesys Cloud's integration (InteractionSync for D365) to identify and lock in the customer context at the start of the call. InteractionSync will typically do an automated screen-pop in Dynamics, searching for the incoming caller's record and opening it for the agent[2]. It also automatically creates a Dynamics activity (e.g. Phone Call record) for the interaction and associates it to the found contact/lead/account[2]. This means as soon as the call begins (and the caller is identified), there is a specific CRM record tied to the interaction. Ensure this screen-pop and activity creation is working reliably for your queues (configure the integration's lookup logic so that it finds the correct member by phone number or other identifiers). If the integration cannot find a match and the agent must search manually, make it a standard operating procedure that the agent selects or creates the correct member record before proceeding further. In summary: do not let the call progress to wrap-up or summary generation without an attached CRM context. This is the foundation – the Co-Pilot summary feature needs that "anchor" to a Dynamics record.
• 2. Gating Auto-Summarization on Context: Out-of-the-box, Agent Co-Pilot will generate a summary when an interaction is completed (disconnected) as long as the feature is enabled for that interaction type[3][4]. You can't truly "stop" Co-Pilot from attempting to summarize a conversation it handled – but you can gate whether that summary gets used or pushed to CRM. One strategy is to configure Co-Pilot or your business rules such that summarization is expected only in certain scenarios (for example, enable Co-Pilot on queues or interactions that are likely to have an identified customer). If an interaction ends and no Dynamics record was ever opened (meaning the call remained anonymous), simply do not transfer the summary anywhere. It will exist in Genesys for a brief period (by design, Co-Pilot summaries are stored for 10 days internally[5]), but your integration should treat it as a no-op in terms of CRM. In effect, Co-Pilot is "paused" waiting for a valid customer context. As soon as the agent does identify/open a member record (even if mid-call), that event can serve as the green light to resume or consider summarization active. If your integration is capable, you might even programmatically trigger the summary generation at that moment (e.g. by calling the summarization API at call end, once context is confirmed). The key is that no summary leaves Genesys Cloud unless a member context is set.
• 3. Hooking into Context Changes (Start/Stop): It's important to tie into the events of your CRM UI so you know when an agent has opened or closed a member's record. In Dynamics 365 (especially with the multi-session interface for Customer Service), each session/tab corresponds to a customer issue or account context. The Genesys integration can be extended via the Dynamics Channel Integration Framework (CIF) or client-side scripts to detect when a new session starts or ends. For example:

·       When a screen pop occurs and opens a contact, have that trigger a "Start Summarization" event in your logic. This could be as simple as setting a flag in the Genesys conversation's participant data that "CRM Context = [ContactID] established", or enabling a timer/collection of transcript for summary. From this point, Co-Pilot can continue transcribing and later summarizing, confident there's an associated account.

·       If the agent closes the contact tab or Dynamics session before the call is over (intentionally or accidentally), catch that event to "Pause Summarization." In practice, you might set a flag like "context lost" which tells your post-call routine not to push any summary. You could even alert the agent or require them to re-open the member record. This prevents a scenario where a summary is generated with nowhere in CRM to go.

·       If the agent switches to a different account record during the call (for instance, they realized the initial screen-pop was the wrong John Smith and they pulled up a different John Smith's record), then you should treat that similar to closing one context and starting another. In other words, reset the summarization binding – mark the old context as inactive and the new one as the official context. Technically, the conversation's transcript is continuous, but by resetting and re-binding to the new record, you ensure the final summary will be linked to the correct customer. (If your integration created an activity on the first record, you may need to update it or create a new one on the correct record – the Dynamics "regarding" field of the Phone Call can be changed to the new contact if needed so that all notes and the summary ultimately relate to the right person.)

• Some Genesys–CRM integrations also support an "Associations" feature in the agent's call log, which allows manually re-linking an interaction to a different CRM entity if needed. If your agents use that, tie your summarization logic to the final association they set. Essentially, always refer to the current associated member record when deciding where to send the summary.
• 4. Pushing the Summary to D365 (Finalize on Call End): The actual handoff of the summary to Dynamics should occur at the end of the call, during the after-call work (ACW) phase or immediately after. This is when Genesys Co-Pilot presents the generated summary to the agent in the interface[3]. At this point, your integration or custom process should do a final check: "Do we have a valid Dynamics member ID for this conversation?" If yes, proceed to push; if not, skip it. Pushing the summary can be accomplished in a couple of ways:

·       Manual method: The agent can copy the Co-Pilot summary text from Genesys and paste it into the call notes or a custom field in the Genesys sidebar, which will sync to the Dynamics activity. (As of mid-2024, this was the primary method – Genesys confirmed that Co-Pilot summarization for D365 requires a manual copy/paste into the wrap-up notes field[6].) While this works, it relies on agent diligence and is prone to error if the agent has the wrong record open. You should train agents to double-check the CRM tab before pasting the summary.

·       Automated method: A more robust approach is to use Genesys Cloud's APIs and Data Actions to transfer the summary directly. Genesys provides a Conversation Summaries API which allows you to retrieve the AI-generated summary programmatically[1]. Your integration can call GET /api/v2/conversations/{conversationId}/summaries (with appropriate authorization) once the call is complete to obtain the summary text and any AI-suggested fields (like reason or resolution). Then, using a Genesys Data Action or a custom service, push that summary into Dynamics. For example, you could update the Phone Call activity's description or add a note to the contact's timeline with the summary text. This automation eliminates copy/paste mistakes. Important: Do this only if conversationId is reliably tied to a Dynamics record. You might use a custom conversation attribute or the activity's CRM ID to correlate – for instance, InteractionSync can store Genesys Conversation ID on the Dynamics activity record[7][8]. By using such an identifier, your code can ensure it's updating the correct Dynamics record with the summary.

• In either case, make sure the Dynamics record is still active/valid at push time. If the agent had closed the CRM tab or if the integration did not find any contact, your push logic should detect that and refrain from sending. It's better to have a summary stay in Genesys (where it expires in 10 days) than to accidentally attach it to the wrong customer in D365.
• 5. Resetting Between Sessions: Each interaction (call/chat/etc.) should be treated as a separate summarization session tied to its own CRM context. Once an interaction is fully completed and the summary has (or hasn't) been pushed, you should reset any tracking variables or context flags in your integration layer. The next call an agent handles will likely pertain to a different account, so your logic should start fresh (waiting for a new screen-pop and context establishment). Genesys Cloud's Agent Co-Pilot will naturally separate summaries by conversation ID, so there's no data overlap on Genesys' side. Your job is to mirror that separation in the CRM integration. For example, if you were storing the current Dynamics record ID in a variable during the call, clear it out at call end. This prevents any chance that a new call could accidentally reuse a previous call's context. Also ensure the Genesys UI is reset – typically, the integration will open a new Dynamics activity for the next call, but if an agent manually stayed on an old record, be cautious. It is a best practice to navigate away from the last contact's screen after finishing ACW, or let the integration auto-pop the next one, so that the visible CRM context always matches the active interaction. The Genesys InteractionSync release notes even highlight multi-session management considerations (for example, a known issue was that if an agent opened a record via search rather than the screen-pop, a session ID wasn't generated[9], which could complicate context tracking). Being aware of such limitations, make sure to test and enforce context continuity between Genesys and D365 at the start and end of sessions.

By following the above practices, you effectively create a mechanism where Co-Pilot's summarization is contextually aware of the Dynamics 365 member session. The summary generation might be an automated AI feature, but you are wrapping it in rules that tie it to Dynamics' state: it "starts" when a customer is identified, it "stops" if the customer context is lost, it only "pushes" upon a valid conclusion with the correct customer, and it "resets" when moving to a new session.

Avoiding Cross-Account Contamination

A primary risk in any CRM-integrated summarization is that a summary from one customer interaction ends up attached to a different customer's record. Here are some best practices to prevent this "cross-account contamination":

·       Enforce One-Conversation/One-Record Linking: Ensure that each Genesys conversation ID is linked to at most one Dynamics record. If your agent tries to handle multiple accounts in one call (e.g. the caller asks about two different people's info – a rare but possible scenario), do not attempt to use one summary for both. Instead, the agent should split the call or notes accordingly. The integration should log the call under one primary contact or case in Dynamics. By keeping this one-to-one mapping, you eliminate ambiguity about where the summary should go.

·       Don't Share Summary Content Across Accounts: Never copy a summary from one member's activity into another's. If information from a call needs to be noted on two accounts (for instance, a conference call involving two clients), it's better to have the agent write separate notes for the second account manually. The Co-Pilot summary is tailored to the single interaction and should remain attached only to the records that were part of that interaction.

·       Use Unique Identifiers for Verification: As mentioned, leverage identifiers like the Genesys conversation ID or the Dynamics activity ID to track the linkage. Many organizations add a custom field in D365 for "Genesys Conversation ID" and populate it for each call activity[7]. This allows you to later audit where a summary was attached. If you ever see the same conversation ID on two different contact records, that's a red flag.

·       Train Agents on the Integration Workflow: Sometimes contamination happens due to human error – e.g. an agent might forget to switch the CRM record when a caller reveals new information ("Actually, I'm calling about my spouse's account, not mine"). Make sure agents know to update the CRM context ASAP in such cases (perhaps using the "Associations" feature to relink the call if needed). If they do that, your integration logic (start/stop/reset as discussed) should handle the rest – but the agent's awareness is the first line of defense.

·       Handle Multi-Tab Concurrency Carefully: If your agents can have multiple customer sessions open concurrently (for example, handling two chats at once with two different members), verify that the Genesys integration truly sandboxes each session. Co-Pilot should be running separately for each conversation. The risk here is lower because Genesys Cloud will generate two distinct summaries for two distinct interactions, but ensure your UI makes it clear which summary belongs to which session. Dynamics 365's multi-session interface usually keeps activities separated by tabs, and each Genesys interaction is associated with the correct tab when using the official integration. Still, it's wise to test this: have an agent handle two interactions and confirm that each Dynamics activity gets the correct notes and summary.

·       Monitor and Log Summary Pushes: Implement logging around the summary push operation. For example, if using a custom Data Action to send the summary to D365, log the conversation ID, target CRM entity, and timestamp. This way, if anything does go awry, you can trace it. Regularly review a few records to ensure summaries are appearing where they should.

·       Beware of "Stale" CRM Context: A common edge-case: the agent ends a call but leaves the Dynamics tab open on that contact, then later takes a new call and forgets that the old tab is still open. If your integration doesn't automatically pop a new tab (say the new call comes in unknown and doesn't pop), the agent might inadvertently paste a summary into the wrong contact's notes. To mitigate this, configure the integration to either always open a new session for each interaction (preferred), or have agents close out old sessions. Some integrations will auto-focus the relevant tab or update it; ensure that behavior is working. Using the session reset best practice from earlier (clearing context between calls) will help avoid this scenario.

In short, maintaining a strong binding between the conversation and the CRM record throughout the call prevents leakage of data across accounts. Each context change is an opportunity to either reinforce the correct link or to halt summarization until the link is corrected.

Verification and Testing

Implementing these controls is only half the battle – you'll want to rigorously test the summarization lifecycle to be confident it behaves as expected. Here are recommended techniques for verification:

·       Simulate Normal Calls: Place test calls where the caller matches exactly one Dynamics contact (or member account). Ensure the integration screen-pops that contact, the call logs to that contact's record, and when the call ends, the Co-Pilot summary appears only on that contact's timeline or activity. Verify that the summary content in D365 matches what Genesys Co-Pilot displayed. This tests the happy path end-to-end.

·       Test No-Context Scenario: Simulate a call from an unknown number that isn't in D365. The integration likely will not pop a contact (it might open a blank search or "new contact" form). Do not select or create any contact – let the call conclude without an associated record. The expectation: Co-Pilot may still generate a summary in the Genesys UI for the agent's reference, but no summary or call activity should appear in Dynamics. Check that no activity was inadvertently created, or if one was (some systems log the call to a generic record), confirm its notes are empty. Essentially, confirm that your "no context, no push" rule is honored.

·       Test Context Gained Mid-Call: Start a call with no initial CRM match, then during the call have the agent manually find and open the correct member record (perhaps the caller provides an email or account number that allows a manual search). Ensure that once the record is open, the rest of the call is logged under that record. When the call ends, the summary should be pushed to that newly selected record's activity. Check that the summary did attach to it, and nowhere else. This verifies that your late-binding of context still triggers the summary push correctly.

·       Test Context Switch Mid-Call: More complex: use a scenario where the wrong contact pops first. For example, two contacts with the same name and your integration pops the first one. Have the agent realize the mistake and switch to the second contact's record while on the call. After call completion, verify that the summary went to the second (correct) contact's record and that the first contact's record (which was initially opened) does not have any summary or has the activity reassigned. This is a crucial test for the "switch and reset" logic.

·       Concurrent Interactions: If applicable, have an agent handle two interactions concurrently (if your business allows, e.g. a voice call and a chat, or two chats). Confirm that two separate summaries are generated and each is pushed to the appropriate Dynamics record. The agent's interface should clearly separate the two (Dynamics will have two activities in two sessions). This test ensures no overlap in multi-tasking scenarios.

·       Long Calls and Edge Cases: Test a long call (over 30-40 minutes) to ensure summarization still functions (Genesys summarization might not produce output if conversation exceeds certain lengths[10]). Also test calls that transfer between agents: if your workflow involves transfers, ensure that when Agent A transfers to Agent B, the summary of Agent A's portion goes to the correct record and Agent B's summary goes to the correct record. (Out of the box, each agent gets their own summary for their portion[11][12]. In a CRM context, both parts should ideally log to the same customer's history – make sure your integration doesn't open a new contact for the second agent erroneously.)

·       Review Audit Trails: After testing, review the Dynamics records and Genesys conversation details. Check that each Dynamics activity has the right Genesys conversation ID (if you map it) and that it matches the conversation where the summary came from. Utilize Genesys's analytics or quality tools to cross-verify content if needed. Also consider enabling debug logging in InteractionSync (Genesys integration) during testing; it can show events like screen-pop, association changes, etc., which help confirm your "start/stop" hooks fired correctly.

By performing the above tests, you can be confident that Agent Co-Pilot summaries are being handled in a controlled, context-sensitive manner. Any discrepancies found should be addressed by refining the integration logic or user procedure before going live.

Conclusion

In a Genesys Cloud + Microsoft Dynamics 365 environment, tying AI summaries to the correct member account is essential for data accuracy, security, and usefulness. The Genesys Agent Co-Pilot feature is powerful, but without the proper context binding, its summaries could end up in the wrong place or at the wrong time. By enforcing that a valid D365 member session is in place for every summary, and by using lifecycle hooks to start, stop, push, or reset summarization based on CRM context, you create a tight coupling between the conversation and the CRM record. This not only prevents cross-account contamination of notes, but also ensures agents and supervisors can trust the summaries they see in Dynamics.

From a practical standpoint, implement the solution using the tools at your disposal: InteractionSync's screen-pop and activity mapping, Genesys conversation attributes and Summaries API, and Dynamics CIF events or custom scripting. Always fail safe – if something isn't right (no context, or context changed), err on the side of not pushing the summary automatically. It's better to have an agent manually intervene in an edge case than to have a summary attached to the wrong account. Finally, continuously monitor and refine the process. As Genesys and Microsoft update their integrations (for example, adding native support for summary injection in future releases), adapt your strategy to take advantage of those while keeping the fundamental requirement in mind: each summary goes to the one and only correct member record.

By following these best practices, Genesys Cloud administrators and developers can confidently deploy Agent Co-Pilot summarization in tandem with Dynamics 365, knowing that the right information will reach the right customer record every time. Your CRM will remain clean and accurate, and your agents will gain efficiency from AI summaries without introducing risk.

Tightly Binding Agent Co-Pilot Summaries to the Correct D365 Member Account

Introduction

Genesys Cloud's Agent Co-Pilot can automatically generate a summary of each customer interaction, which is extremely useful for after-call work. However, when integrating with Microsoft Dynamics 365 (D365), it's critical to ensure these AI-generated summaries are only pushed to the correct member's account record. If a summary is attached to the wrong account, it can lead to serious data integrity and privacy issues (often called cross-account contamination). The goal is to tightly bind the Co-Pilot summarization lifecycle – from start through push – to the active D365 customer context. In practice, this means the Co-Pilot summary process must be context-aware and only operate when an agent has a confirmed D365 member record open for the interaction. Genesys Cloud does support querying and exporting conversation summaries via API for CRM integration[1], but it's up to administrators and developers to implement the proper safeguards so summaries go to the right place. Below we outline the functional requirements and best practices for achieving this binding.

Key Functional Requirements

To guarantee that Co-Pilot summaries are linked to the correct Dynamics account, the following requirements must be met:

·       Context before Summarization: Summarization must not begin until a Dynamics 365 member account record is actively open/identified. In other words, Co-Pilot's auto-summary should only activate after the agent is viewing a confirmed customer record in D365. If an interaction isn't yet tied to a CRM contact/lead/account, the summarization feature should remain idle (or in a paused state).

·       No Context = No Summaries: If no D365 member record is open, Co-Pilot should not generate or display a summary. The system should effectively prevent or delay any auto-summarization when the CRM context is missing. This ensures you don't produce a summary that might accidentally be saved to the wrong place or require manual handling.

·       Validated Member for Push: When the call ends, push the summary to D365 only if a valid, active member record has been confirmed for that interaction. The integration must double-check that the conversation is associated with a specific Dynamics contact/account before transferring the summary text. If the CRM context was never set (or was lost), the summary should not be auto-sent into D365.

·       Reset on Session Change: If the agent closes the current member's session or switches to a different account record mid-interaction, the summarization process should reset. Any ongoing or pending summarization tied to the previous context should be cleared or halted to avoid mixing content between accounts. Essentially, Co-Pilot's summary lifecycle should be tightly scoped to one CRM session – when the agent moves to another customer or a new session, it should treat it as a fresh start.

·       Explicit Lifecycle Controls: Provide clear controls or hooks for "start, stop, push, reset" that are triggered by D365 context events. In practice, this means your integration or custom code should listen for events like record opened, record closed, record changed, and invoke the appropriate summarization control:

·       Start when a D365 member context is established (e.g. agent has an active contact open).

·       Stop/Pause if the context is removed or unknown (e.g. agent navigates away or no contact selected).

·       Push when ready to send the final summary to CRM (e.g. on call completion, if context is valid).

·       Reset when the session ends or the agent switches context (clearing any state so the next interaction starts cleanly).

These requirements enforce that an Agent Co-Pilot summary is always explicitly linked to a single, correct Dynamics 365 member record throughout its creation and delivery.

Implementing a Context-Bound Summarization Lifecycle

Meeting the above requirements involves configuring the Genesys–D365 integration and possibly adding custom logic. Below are best practices and implementation guidelines to tightly bind the summarization lifecycle to the CRM context:

• 1. Establish CRM Context Before Summarization: Leverage Genesys Cloud's integration (InteractionSync for D365) to identify and lock in the customer context at the start of the call. InteractionSync will typically do an automated screen-pop in Dynamics, searching for the incoming caller's record and opening it for the agent[2]. It also automatically creates a Dynamics activity (e.g. Phone Call record) for the interaction and associates it to the found contact/lead/account[2]. This means as soon as the call begins (and the caller is identified), there is a specific CRM record tied to the interaction. Ensure this screen-pop and activity creation is working reliably for your queues (configure the integration's lookup logic so that it finds the correct member by phone number or other identifiers). If the integration cannot find a match and the agent must search manually, make it a standard operating procedure that the agent selects or creates the correct member record before proceeding further. In summary: do not let the call progress to wrap-up or summary generation without an attached CRM context. This is the foundation – the Co-Pilot summary feature needs that "anchor" to a Dynamics record.
• 2. Gating Auto-Summarization on Context: Out-of-the-box, Agent Co-Pilot will generate a summary when an interaction is completed (disconnected) as long as the feature is enabled for that interaction type[3][4]. You can't truly "stop" Co-Pilot from attempting to summarize a conversation it handled – but you can gate whether that summary gets used or pushed to CRM. One strategy is to configure Co-Pilot or your business rules such that summarization is expected only in certain scenarios (for example, enable Co-Pilot on queues or interactions that are likely to have an identified customer). If an interaction ends and no Dynamics record was ever opened (meaning the call remained anonymous), simply do not transfer the summary anywhere. It will exist in Genesys for a brief period (by design, Co-Pilot summaries are stored for 10 days internally[5]), but your integration should treat it as a no-op in terms of CRM. In effect, Co-Pilot is "paused" waiting for a valid customer context. As soon as the agent does identify/open a member record (even if mid-call), that event can serve as the green light to resume or consider summarization active. If your integration is capable, you might even programmatically trigger the summary generation at that moment (e.g. by calling the summarization API at call end, once context is confirmed). The key is that no summary leaves Genesys Cloud unless a member context is set.
• 3. Hooking into Context Changes (Start/Stop): It's important to tie into the events of your CRM UI so you know when an agent has opened or closed a member's record. In Dynamics 365 (especially with the multi-session interface for Customer Service), each session/tab corresponds to a customer issue or account context. The Genesys integration can be extended via the Dynamics Channel Integration Framework (CIF) or client-side scripts to detect when a new session starts or ends. For example:

·       When a screen pop occurs and opens a contact, have that trigger a "Start Summarization" event in your logic. This could be as simple as setting a flag in the Genesys conversation's participant data that "CRM Context = [ContactID] established", or enabling a timer/collection of transcript for summary. From this point, Co-Pilot can continue transcribing and later summarizing, confident there's an associated account.

·       If the agent closes the contact tab or Dynamics session before the call is over (intentionally or accidentally), catch that event to "Pause Summarization." In practice, you might set a flag like "context lost" which tells your post-call routine not to push any summary. You could even alert the agent or require them to re-open the member record. This prevents a scenario where a summary is generated with nowhere in CRM to go.

·       If the agent switches to a different account record during the call (for instance, they realized the initial screen-pop was the wrong John Smith and they pulled up a different John Smith's record), then you should treat that similar to closing one context and starting another. In other words, reset the summarization binding – mark the old context as inactive and the new one as the official context. Technically, the conversation's transcript is continuous, but by resetting and re-binding to the new record, you ensure the final summary will be linked to the correct customer. (If your integration created an activity on the first record, you may need to update it or create a new one on the correct record – the Dynamics "regarding" field of the Phone Call can be changed to the new contact if needed so that all notes and the summary ultimately relate to the right person.)

• Some Genesys–CRM integrations also support an "Associations" feature in the agent's call log, which allows manually re-linking an interaction to a different CRM entity if needed. If your agents use that, tie your summarization logic to the final association they set. Essentially, always refer to the current associated member record when deciding where to send the summary.
• 4. Pushing the Summary to D365 (Finalize on Call End): The actual handoff of the summary to Dynamics should occur at the end of the call, during the after-call work (ACW) phase or immediately after. This is when Genesys Co-Pilot presents the generated summary to the agent in the interface[3]. At this point, your integration or custom process should do a final check: "Do we have a valid Dynamics member ID for this conversation?" If yes, proceed to push; if not, skip it. Pushing the summary can be accomplished in a couple of ways:

·       Manual method: The agent can copy the Co-Pilot summary text from Genesys and paste it into the call notes or a custom field in the Genesys sidebar, which will sync to the Dynamics activity. (As of mid-2024, this was the primary method – Genesys confirmed that Co-Pilot summarization for D365 requires a manual copy/paste into the wrap-up notes field[6].) While this works, it relies on agent diligence and is prone to error if the agent has the wrong record open. You should train agents to double-check the CRM tab before pasting the summary.

·       Automated method: A more robust approach is to use Genesys Cloud's APIs and Data Actions to transfer the summary directly. Genesys provides a Conversation Summaries API which allows you to retrieve the AI-generated summary programmatically[1]. Your integration can call GET /api/v2/conversations/{conversationId}/summaries (with appropriate authorization) once the call is complete to obtain the summary text and any AI-suggested fields (like reason or resolution). Then, using a Genesys Data Action or a custom service, push that summary into Dynamics. For example, you could update the Phone Call activity's description or add a note to the contact's timeline with the summary text. This automation eliminates copy/paste mistakes. Important: Do this only if conversationId is reliably tied to a Dynamics record. You might use a custom conversation attribute or the activity's CRM ID to correlate – for instance, InteractionSync can store Genesys Conversation ID on the Dynamics activity record[7][8]. By using such an identifier, your code can ensure it's updating the correct Dynamics record with the summary.

• In either case, make sure the Dynamics record is still active/valid at push time. If the agent had closed the CRM tab or if the integration did not find any contact, your push logic should detect that and refrain from sending. It's better to have a summary stay in Genesys (where it expires in 10 days) than to accidentally attach it to the wrong customer in D365.
• 5. Resetting Between Sessions: Each interaction (call/chat/etc.) should be treated as a separate summarization session tied to its own CRM context. Once an interaction is fully completed and the summary has (or hasn't) been pushed, you should reset any tracking variables or context flags in your integration layer. The next call an agent handles will likely pertain to a different account, so your logic should start fresh (waiting for a new screen-pop and context establishment). Genesys Cloud's Agent Co-Pilot will naturally separate summaries by conversation ID, so there's no data overlap on Genesys' side. Your job is to mirror that separation in the CRM integration. For example, if you were storing the current Dynamics record ID in a variable during the call, clear it out at call end. This prevents any chance that a new call could accidentally reuse a previous call's context. Also ensure the Genesys UI is reset – typically, the integration will open a new Dynamics activity for the next call, but if an agent manually stayed on an old record, be cautious. It is a best practice to navigate away from the last contact's screen after finishing ACW, or let the integration auto-pop the next one, so that the visible CRM context always matches the active interaction. The Genesys InteractionSync release notes even highlight multi-session management considerations (for example, a known issue was that if an agent opened a record via search rather than the screen-pop, a session ID wasn't generated[9], which could complicate context tracking). Being aware of such limitations, make sure to test and enforce context continuity between Genesys and D365 at the start and end of sessions.

By following the above practices, you effectively create a mechanism where Co-Pilot's summarization is contextually aware of the Dynamics 365 member session. The summary generation might be an automated AI feature, but you are wrapping it in rules that tie it to Dynamics' state: it "starts" when a customer is identified, it "stops" if the customer context is lost, it only "pushes" upon a valid conclusion with the correct customer, and it "resets" when moving to a new session.

Avoiding Cross-Account Contamination

A primary risk in any CRM-integrated summarization is that a summary from one customer interaction ends up attached to a different customer's record. Here are some best practices to prevent this "cross-account contamination":

·       Enforce One-Conversation/One-Record Linking: Ensure that each Genesys conversation ID is linked to at most one Dynamics record. If your agent tries to handle multiple accounts in one call (e.g. the caller asks about two different people's info – a rare but possible scenario), do not attempt to use one summary for both. Instead, the agent should split the call or notes accordingly. The integration should log the call under one primary contact or case in Dynamics. By keeping this one-to-one mapping, you eliminate ambiguity about where the summary should go.

·       Don't Share Summary Content Across Accounts: Never copy a summary from one member's activity into another's. If information from a call needs to be noted on two accounts (for instance, a conference call involving two clients), it's better to have the agent write separate notes for the second account manually. The Co-Pilot summary is tailored to the single interaction and should remain attached only to the records that were part of that interaction.

·       Use Unique Identifiers for Verification: As mentioned, leverage identifiers like the Genesys conversation ID or the Dynamics activity ID to track the linkage. Many organizations add a custom field in D365 for "Genesys Conversation ID" and populate it for each call activity[7]. This allows you to later audit where a summary was attached. If you ever see the same conversation ID on two different contact records, that's a red flag.

·       Train Agents on the Integration Workflow: Sometimes contamination happens due to human error – e.g. an agent might forget to switch the CRM record when a caller reveals new information ("Actually, I'm calling about my spouse's account, not mine"). Make sure agents know to update the CRM context ASAP in such cases (perhaps using the "Associations" feature to relink the call if needed). If they do that, your integration logic (start/stop/reset as discussed) should handle the rest – but the agent's awareness is the first line of defense.

·       Handle Multi-Tab Concurrency Carefully: If your agents can have multiple customer sessions open concurrently (for example, handling two chats at once with two different members), verify that the Genesys integration truly sandboxes each session. Co-Pilot should be running separately for each conversation. The risk here is lower because Genesys Cloud will generate two distinct summaries for two distinct interactions, but ensure your UI makes it clear which summary belongs to which session. Dynamics 365's multi-session interface usually keeps activities separated by tabs, and each Genesys interaction is associated with the correct tab when using the official integration. Still, it's wise to test this: have an agent handle two interactions and confirm that each Dynamics activity gets the correct notes and summary.

·       Monitor and Log Summary Pushes: Implement logging around the summary push operation. For example, if using a custom Data Action to send the summary to D365, log the conversation ID, target CRM entity, and timestamp. This way, if anything does go awry, you can trace it. Regularly review a few records to ensure summaries are appearing where they should.

·       Beware of "Stale" CRM Context: A common edge-case: the agent ends a call but leaves the Dynamics tab open on that contact, then later takes a new call and forgets that the old tab is still open. If your integration doesn't automatically pop a new tab (say the new call comes in unknown and doesn't pop), the agent might inadvertently paste a summary into the wrong contact's notes. To mitigate this, configure the integration to either always open a new session for each interaction (preferred), or have agents close out old sessions. Some integrations will auto-focus the relevant tab or update it; ensure that behavior is working. Using the session reset best practice from earlier (clearing context between calls) will help avoid this scenario.

In short, maintaining a strong binding between the conversation and the CRM record throughout the call prevents leakage of data across accounts. Each context change is an opportunity to either reinforce the correct link or to halt summarization until the link is corrected.

Verification and Testing

Implementing these controls is only half the battle – you'll want to rigorously test the summarization lifecycle to be confident it behaves as expected. Here are recommended techniques for verification:

·       Simulate Normal Calls: Place test calls where the caller matches exactly one Dynamics contact (or member account). Ensure the integration screen-pops that contact, the call logs to that contact's record, and when the call ends, the Co-Pilot summary appears only on that contact's timeline or activity. Verify that the summary content in D365 matches what Genesys Co-Pilot displayed. This tests the happy path end-to-end.

·       Test No-Context Scenario: Simulate a call from an unknown number that isn't in D365. The integration likely will not pop a contact (it might open a blank search or "new contact" form). Do not select or create any contact – let the call conclude without an associated record. The expectation: Co-Pilot may still generate a summary in the Genesys UI for the agent's reference, but no summary or call activity should appear in Dynamics. Check that no activity was inadvertently created, or if one was (some systems log the call to a generic record), confirm its notes are empty. Essentially, confirm that your "no context, no push" rule is honored.

·       Test Context Gained Mid-Call: Start a call with no initial CRM match, then during the call have the agent manually find and open the correct member record (perhaps the caller provides an email or account number that allows a manual search). Ensure that once the record is open, the rest of the call is logged under that record. When the call ends, the summary should be pushed to that newly selected record's activity. Check that the summary did attach to it, and nowhere else. This verifies that your late-binding of context still triggers the summary push correctly.

·       Test Context Switch Mid-Call: More complex: use a scenario where the wrong contact pops first. For example, two contacts with the same name and your integration pops the first one. Have the agent realize the mistake and switch to the second contact's record while on the call. After call completion, verify that the summary went to the second (correct) contact's record and that the first contact's record (which was initially opened) does not have any summary or has the activity reassigned. This is a crucial test for the "switch and reset" logic.

·       Concurrent Interactions: If applicable, have an agent handle two interactions concurrently (if your business allows, e.g. a voice call and a chat, or two chats). Confirm that two separate summaries are generated and each is pushed to the appropriate Dynamics record. The agent's interface should clearly separate the two (Dynamics will have two activities in two sessions). This test ensures no overlap in multi-tasking scenarios.

·       Long Calls and Edge Cases: Test a long call (over 30-40 minutes) to ensure summarization still functions (Genesys summarization might not produce output if conversation exceeds certain lengths[10]). Also test calls that transfer between agents: if your workflow involves transfers, ensure that when Agent A transfers to Agent B, the summary of Agent A's portion goes to the correct record and Agent B's summary goes to the correct record. (Out of the box, each agent gets their own summary for their portion[11][12]. In a CRM context, both parts should ideally log to the same customer's history – make sure your integration doesn't open a new contact for the second agent erroneously.)

·       Review Audit Trails: After testing, review the Dynamics records and Genesys conversation details. Check that each Dynamics activity has the right Genesys conversation ID (if you map it) and that it matches the conversation where the summary came from. Utilize Genesys's analytics or quality tools to cross-verify content if needed. Also consider enabling debug logging in InteractionSync (Genesys integration) during testing; it can show events like screen-pop, association changes, etc., which help confirm your "start/stop" hooks fired correctly.

By performing the above tests, you can be confident that Agent Co-Pilot summaries are being handled in a controlled, context-sensitive manner. Any discrepancies found should be addressed by refining the integration logic or user procedure before going live.

Conclusion

In a Genesys Cloud + Microsoft Dynamics 365 environment, tying AI summaries to the correct member account is essential for data accuracy, security, and usefulness. The Genesys Agent Co-Pilot feature is powerful, but without the proper context binding, its summaries could end up in the wrong place or at the wrong time. By enforcing that a valid D365 member session is in place for every summary, and by using lifecycle hooks to start, stop, push, or reset summarization based on CRM context, you create a tight coupling between the conversation and the CRM record. This not only prevents cross-account contamination of notes, but also ensures agents and supervisors can trust the summaries they see in Dynamics.

From a practical standpoint, implement the solution using the tools at your disposal: InteractionSync's screen-pop and activity mapping, Genesys conversation attributes and Summaries API, and Dynamics CIF events or custom scripting. Always fail safe – if something isn't right (no context, or context changed), err on the side of not pushing the summary automatically. It's better to have an agent manually intervene in an edge case than to have a summary attached to the wrong account. Finally, continuously monitor and refine the process. As Genesys and Microsoft update their integrations (for example, adding native support for summary injection in future releases), adapt your strategy to take advantage of those while keeping the fundamental requirement in mind: each summary goes to the one and only correct member record.

By following these best practices, Genesys Cloud administrators and developers can confidently deploy Agent Co-Pilot summarization in tandem with Dynamics 365, knowing that the right information will reach the right customer record every time. Your CRM will remain clean and accurate, and your agents will gain efficiency from AI summaries without introducing risk.

Hi Alex,

First - wow! Thank you for the detailed idea. It would be great to break this up into a few components and add to our Idea Hub. I can track and note there.

There are two features that are upcoming that could be used as a workaround. The first is on-demand summaries and the second is setting the Time-To-Live for generated summaries. 

On-demand would allow you to generate a summary during a call with an agent. This way, you could potentially check where you want the summary stored and then set an action close to the end of the interaction to generate the summary via API. 

Time-to-live would allow you to delete summaries for a particular queue so they aren't stored unless you save them where specified within the time-to-live period (minimum being two hours). 

While these two features could be used to cobble together a solution, it would be easier if we were to implement more configurations are who, when, and how a summary is generated. Will be taking this into consideration for our next updates.

Very grateful!

Leor

Tightly Binding Agent Co-Pilot Summaries to the Correct D365 Member Account

Introduction

Genesys Cloud's Agent Co-Pilot can automatically generate a summary of each customer interaction, which is extremely useful for after-call work. However, when integrating with Microsoft Dynamics 365 (D365), it's critical to ensure these AI-generated summaries are only pushed to the correct member's account record. If a summary is attached to the wrong account, it can lead to serious data integrity and privacy issues (often called cross-account contamination). The goal is to tightly bind the Co-Pilot summarization lifecycle – from start through push – to the active D365 customer context. In practice, this means the Co-Pilot summary process must be context-aware and only operate when an agent has a confirmed D365 member record open for the interaction. Genesys Cloud does support querying and exporting conversation summaries via API for CRM integration[1], but it's up to administrators and developers to implement the proper safeguards so summaries go to the right place. Below we outline the functional requirements and best practices for achieving this binding.

Key Functional Requirements

To guarantee that Co-Pilot summaries are linked to the correct Dynamics account, the following requirements must be met:

·       Context before Summarization: Summarization must not begin until a Dynamics 365 member account record is actively open/identified. In other words, Co-Pilot's auto-summary should only activate after the agent is viewing a confirmed customer record in D365. If an interaction isn't yet tied to a CRM contact/lead/account, the summarization feature should remain idle (or in a paused state).

·       No Context = No Summaries: If no D365 member record is open, Co-Pilot should not generate or display a summary. The system should effectively prevent or delay any auto-summarization when the CRM context is missing. This ensures you don't produce a summary that might accidentally be saved to the wrong place or require manual handling.

·       Validated Member for Push: When the call ends, push the summary to D365 only if a valid, active member record has been confirmed for that interaction. The integration must double-check that the conversation is associated with a specific Dynamics contact/account before transferring the summary text. If the CRM context was never set (or was lost), the summary should not be auto-sent into D365.

·       Reset on Session Change: If the agent closes the current member's session or switches to a different account record mid-interaction, the summarization process should reset. Any ongoing or pending summarization tied to the previous context should be cleared or halted to avoid mixing content between accounts. Essentially, Co-Pilot's summary lifecycle should be tightly scoped to one CRM session – when the agent moves to another customer or a new session, it should treat it as a fresh start.

·       Explicit Lifecycle Controls: Provide clear controls or hooks for "start, stop, push, reset" that are triggered by D365 context events. In practice, this means your integration or custom code should listen for events like record opened, record closed, record changed, and invoke the appropriate summarization control:

·       Start when a D365 member context is established (e.g. agent has an active contact open).

·       Stop/Pause if the context is removed or unknown (e.g. agent navigates away or no contact selected).

·       Push when ready to send the final summary to CRM (e.g. on call completion, if context is valid).

·       Reset when the session ends or the agent switches context (clearing any state so the next interaction starts cleanly).

These requirements enforce that an Agent Co-Pilot summary is always explicitly linked to a single, correct Dynamics 365 member record throughout its creation and delivery.

Implementing a Context-Bound Summarization Lifecycle

Meeting the above requirements involves configuring the Genesys–D365 integration and possibly adding custom logic. Below are best practices and implementation guidelines to tightly bind the summarization lifecycle to the CRM context:

• 1. Establish CRM Context Before Summarization: Leverage Genesys Cloud's integration (InteractionSync for D365) to identify and lock in the customer context at the start of the call. InteractionSync will typically do an automated screen-pop in Dynamics, searching for the incoming caller's record and opening it for the agent[2]. It also automatically creates a Dynamics activity (e.g. Phone Call record) for the interaction and associates it to the found contact/lead/account[2]. This means as soon as the call begins (and the caller is identified), there is a specific CRM record tied to the interaction. Ensure this screen-pop and activity creation is working reliably for your queues (configure the integration's lookup logic so that it finds the correct member by phone number or other identifiers). If the integration cannot find a match and the agent must search manually, make it a standard operating procedure that the agent selects or creates the correct member record before proceeding further. In summary: do not let the call progress to wrap-up or summary generation without an attached CRM context. This is the foundation – the Co-Pilot summary feature needs that "anchor" to a Dynamics record.
• 2. Gating Auto-Summarization on Context: Out-of-the-box, Agent Co-Pilot will generate a summary when an interaction is completed (disconnected) as long as the feature is enabled for that interaction type[3][4]. You can't truly "stop" Co-Pilot from attempting to summarize a conversation it handled – but you can gate whether that summary gets used or pushed to CRM. One strategy is to configure Co-Pilot or your business rules such that summarization is expected only in certain scenarios (for example, enable Co-Pilot on queues or interactions that are likely to have an identified customer). If an interaction ends and no Dynamics record was ever opened (meaning the call remained anonymous), simply do not transfer the summary anywhere. It will exist in Genesys for a brief period (by design, Co-Pilot summaries are stored for 10 days internally[5]), but your integration should treat it as a no-op in terms of CRM. In effect, Co-Pilot is "paused" waiting for a valid customer context. As soon as the agent does identify/open a member record (even if mid-call), that event can serve as the green light to resume or consider summarization active. If your integration is capable, you might even programmatically trigger the summary generation at that moment (e.g. by calling the summarization API at call end, once context is confirmed). The key is that no summary leaves Genesys Cloud unless a member context is set.
• 3. Hooking into Context Changes (Start/Stop): It's important to tie into the events of your CRM UI so you know when an agent has opened or closed a member's record. In Dynamics 365 (especially with the multi-session interface for Customer Service), each session/tab corresponds to a customer issue or account context. The Genesys integration can be extended via the Dynamics Channel Integration Framework (CIF) or client-side scripts to detect when a new session starts or ends. For example:

·       When a screen pop occurs and opens a contact, have that trigger a "Start Summarization" event in your logic. This could be as simple as setting a flag in the Genesys conversation's participant data that "CRM Context = [ContactID] established", or enabling a timer/collection of transcript for summary. From this point, Co-Pilot can continue transcribing and later summarizing, confident there's an associated account.

·       If the agent closes the contact tab or Dynamics session before the call is over (intentionally or accidentally), catch that event to "Pause Summarization." In practice, you might set a flag like "context lost" which tells your post-call routine not to push any summary. You could even alert the agent or require them to re-open the member record. This prevents a scenario where a summary is generated with nowhere in CRM to go.

·       If the agent switches to a different account record during the call (for instance, they realized the initial screen-pop was the wrong John Smith and they pulled up a different John Smith's record), then you should treat that similar to closing one context and starting another. In other words, reset the summarization binding – mark the old context as inactive and the new one as the official context. Technically, the conversation's transcript is continuous, but by resetting and re-binding to the new record, you ensure the final summary will be linked to the correct customer. (If your integration created an activity on the first record, you may need to update it or create a new one on the correct record – the Dynamics "regarding" field of the Phone Call can be changed to the new contact if needed so that all notes and the summary ultimately relate to the right person.)

• Some Genesys–CRM integrations also support an "Associations" feature in the agent's call log, which allows manually re-linking an interaction to a different CRM entity if needed. If your agents use that, tie your summarization logic to the final association they set. Essentially, always refer to the current associated member record when deciding where to send the summary.
• 4. Pushing the Summary to D365 (Finalize on Call End): The actual handoff of the summary to Dynamics should occur at the end of the call, during the after-call work (ACW) phase or immediately after. This is when Genesys Co-Pilot presents the generated summary to the agent in the interface[3]. At this point, your integration or custom process should do a final check: "Do we have a valid Dynamics member ID for this conversation?" If yes, proceed to push; if not, skip it. Pushing the summary can be accomplished in a couple of ways:

·       Manual method: The agent can copy the Co-Pilot summary text from Genesys and paste it into the call notes or a custom field in the Genesys sidebar, which will sync to the Dynamics activity. (As of mid-2024, this was the primary method – Genesys confirmed that Co-Pilot summarization for D365 requires a manual copy/paste into the wrap-up notes field[6].) While this works, it relies on agent diligence and is prone to error if the agent has the wrong record open. You should train agents to double-check the CRM tab before pasting the summary.

·       Automated method: A more robust approach is to use Genesys Cloud's APIs and Data Actions to transfer the summary directly. Genesys provides a Conversation Summaries API which allows you to retrieve the AI-generated summary programmatically[1]. Your integration can call GET /api/v2/conversations/{conversationId}/summaries (with appropriate authorization) once the call is complete to obtain the summary text and any AI-suggested fields (like reason or resolution). Then, using a Genesys Data Action or a custom service, push that summary into Dynamics. For example, you could update the Phone Call activity's description or add a note to the contact's timeline with the summary text. This automation eliminates copy/paste mistakes. Important: Do this only if conversationId is reliably tied to a Dynamics record. You might use a custom conversation attribute or the activity's CRM ID to correlate – for instance, InteractionSync can store Genesys Conversation ID on the Dynamics activity record[7][8]. By using such an identifier, your code can ensure it's updating the correct Dynamics record with the summary.

• In either case, make sure the Dynamics record is still active/valid at push time. If the agent had closed the CRM tab or if the integration did not find any contact, your push logic should detect that and refrain from sending. It's better to have a summary stay in Genesys (where it expires in 10 days) than to accidentally attach it to the wrong customer in D365.
• 5. Resetting Between Sessions: Each interaction (call/chat/etc.) should be treated as a separate summarization session tied to its own CRM context. Once an interaction is fully completed and the summary has (or hasn't) been pushed, you should reset any tracking variables or context flags in your integration layer. The next call an agent handles will likely pertain to a different account, so your logic should start fresh (waiting for a new screen-pop and context establishment). Genesys Cloud's Agent Co-Pilot will naturally separate summaries by conversation ID, so there's no data overlap on Genesys' side. Your job is to mirror that separation in the CRM integration. For example, if you were storing the current Dynamics record ID in a variable during the call, clear it out at call end. This prevents any chance that a new call could accidentally reuse a previous call's context. Also ensure the Genesys UI is reset – typically, the integration will open a new Dynamics activity for the next call, but if an agent manually stayed on an old record, be cautious. It is a best practice to navigate away from the last contact's screen after finishing ACW, or let the integration auto-pop the next one, so that the visible CRM context always matches the active interaction. The Genesys InteractionSync release notes even highlight multi-session management considerations (for example, a known issue was that if an agent opened a record via search rather than the screen-pop, a session ID wasn't generated[9], which could complicate context tracking). Being aware of such limitations, make sure to test and enforce context continuity between Genesys and D365 at the start and end of sessions.

By following the above practices, you effectively create a mechanism where Co-Pilot's summarization is contextually aware of the Dynamics 365 member session. The summary generation might be an automated AI feature, but you are wrapping it in rules that tie it to Dynamics' state: it "starts" when a customer is identified, it "stops" if the customer context is lost, it only "pushes" upon a valid conclusion with the correct customer, and it "resets" when moving to a new session.

Avoiding Cross-Account Contamination

A primary risk in any CRM-integrated summarization is that a summary from one customer interaction ends up attached to a different customer's record. Here are some best practices to prevent this "cross-account contamination":

·       Enforce One-Conversation/One-Record Linking: Ensure that each Genesys conversation ID is linked to at most one Dynamics record. If your agent tries to handle multiple accounts in one call (e.g. the caller asks about two different people's info – a rare but possible scenario), do not attempt to use one summary for both. Instead, the agent should split the call or notes accordingly. The integration should log the call under one primary contact or case in Dynamics. By keeping this one-to-one mapping, you eliminate ambiguity about where the summary should go.

·       Don't Share Summary Content Across Accounts: Never copy a summary from one member's activity into another's. If information from a call needs to be noted on two accounts (for instance, a conference call involving two clients), it's better to have the agent write separate notes for the second account manually. The Co-Pilot summary is tailored to the single interaction and should remain attached only to the records that were part of that interaction.

·       Use Unique Identifiers for Verification: As mentioned, leverage identifiers like the Genesys conversation ID or the Dynamics activity ID to track the linkage. Many organizations add a custom field in D365 for "Genesys Conversation ID" and populate it for each call activity[7]. This allows you to later audit where a summary was attached. If you ever see the same conversation ID on two different contact records, that's a red flag.

·       Train Agents on the Integration Workflow: Sometimes contamination happens due to human error – e.g. an agent might forget to switch the CRM record when a caller reveals new information ("Actually, I'm calling about my spouse's account, not mine"). Make sure agents know to update the CRM context ASAP in such cases (perhaps using the "Associations" feature to relink the call if needed). If they do that, your integration logic (start/stop/reset as discussed) should handle the rest – but the agent's awareness is the first line of defense.

·       Handle Multi-Tab Concurrency Carefully: If your agents can have multiple customer sessions open concurrently (for example, handling two chats at once with two different members), verify that the Genesys integration truly sandboxes each session. Co-Pilot should be running separately for each conversation. The risk here is lower because Genesys Cloud will generate two distinct summaries for two distinct interactions, but ensure your UI makes it clear which summary belongs to which session. Dynamics 365's multi-session interface usually keeps activities separated by tabs, and each Genesys interaction is associated with the correct tab when using the official integration. Still, it's wise to test this: have an agent handle two interactions and confirm that each Dynamics activity gets the correct notes and summary.

·       Monitor and Log Summary Pushes: Implement logging around the summary push operation. For example, if using a custom Data Action to send the summary to D365, log the conversation ID, target CRM entity, and timestamp. This way, if anything does go awry, you can trace it. Regularly review a few records to ensure summaries are appearing where they should.

·       Beware of "Stale" CRM Context: A common edge-case: the agent ends a call but leaves the Dynamics tab open on that contact, then later takes a new call and forgets that the old tab is still open. If your integration doesn't automatically pop a new tab (say the new call comes in unknown and doesn't pop), the agent might inadvertently paste a summary into the wrong contact's notes. To mitigate this, configure the integration to either always open a new session for each interaction (preferred), or have agents close out old sessions. Some integrations will auto-focus the relevant tab or update it; ensure that behavior is working. Using the session reset best practice from earlier (clearing context between calls) will help avoid this scenario.

In short, maintaining a strong binding between the conversation and the CRM record throughout the call prevents leakage of data across accounts. Each context change is an opportunity to either reinforce the correct link or to halt summarization until the link is corrected.

Verification and Testing

Implementing these controls is only half the battle – you'll want to rigorously test the summarization lifecycle to be confident it behaves as expected. Here are recommended techniques for verification:

·       Simulate Normal Calls: Place test calls where the caller matches exactly one Dynamics contact (or member account). Ensure the integration screen-pops that contact, the call logs to that contact's record, and when the call ends, the Co-Pilot summary appears only on that contact's timeline or activity. Verify that the summary content in D365 matches what Genesys Co-Pilot displayed. This tests the happy path end-to-end.

·       Test No-Context Scenario: Simulate a call from an unknown number that isn't in D365. The integration likely will not pop a contact (it might open a blank search or "new contact" form). Do not select or create any contact – let the call conclude without an associated record. The expectation: Co-Pilot may still generate a summary in the Genesys UI for the agent's reference, but no summary or call activity should appear in Dynamics. Check that no activity was inadvertently created, or if one was (some systems log the call to a generic record), confirm its notes are empty. Essentially, confirm that your "no context, no push" rule is honored.

·       Test Context Gained Mid-Call: Start a call with no initial CRM match, then during the call have the agent manually find and open the correct member record (perhaps the caller provides an email or account number that allows a manual search). Ensure that once the record is open, the rest of the call is logged under that record. When the call ends, the summary should be pushed to that newly selected record's activity. Check that the summary did attach to it, and nowhere else. This verifies that your late-binding of context still triggers the summary push correctly.

·       Test Context Switch Mid-Call: More complex: use a scenario where the wrong contact pops first. For example, two contacts with the same name and your integration pops the first one. Have the agent realize the mistake and switch to the second contact's record while on the call. After call completion, verify that the summary went to the second (correct) contact's record and that the first contact's record (which was initially opened) does not have any summary or has the activity reassigned. This is a crucial test for the "switch and reset" logic.

·       Concurrent Interactions: If applicable, have an agent handle two interactions concurrently (if your business allows, e.g. a voice call and a chat, or two chats). Confirm that two separate summaries are generated and each is pushed to the appropriate Dynamics record. The agent's interface should clearly separate the two (Dynamics will have two activities in two sessions). This test ensures no overlap in multi-tasking scenarios.

·       Long Calls and Edge Cases: Test a long call (over 30-40 minutes) to ensure summarization still functions (Genesys summarization might not produce output if conversation exceeds certain lengths[10]). Also test calls that transfer between agents: if your workflow involves transfers, ensure that when Agent A transfers to Agent B, the summary of Agent A's portion goes to the correct record and Agent B's summary goes to the correct record. (Out of the box, each agent gets their own summary for their portion[11][12]. In a CRM context, both parts should ideally log to the same customer's history – make sure your integration doesn't open a new contact for the second agent erroneously.)

·       Review Audit Trails: After testing, review the Dynamics records and Genesys conversation details. Check that each Dynamics activity has the right Genesys conversation ID (if you map it) and that it matches the conversation where the summary came from. Utilize Genesys's analytics or quality tools to cross-verify content if needed. Also consider enabling debug logging in InteractionSync (Genesys integration) during testing; it can show events like screen-pop, association changes, etc., which help confirm your "start/stop" hooks fired correctly.

By performing the above tests, you can be confident that Agent Co-Pilot summaries are being handled in a controlled, context-sensitive manner. Any discrepancies found should be addressed by refining the integration logic or user procedure before going live.

Conclusion

In a Genesys Cloud + Microsoft Dynamics 365 environment, tying AI summaries to the correct member account is essential for data accuracy, security, and usefulness. The Genesys Agent Co-Pilot feature is powerful, but without the proper context binding, its summaries could end up in the wrong place or at the wrong time. By enforcing that a valid D365 member session is in place for every summary, and by using lifecycle hooks to start, stop, push, or reset summarization based on CRM context, you create a tight coupling between the conversation and the CRM record. This not only prevents cross-account contamination of notes, but also ensures agents and supervisors can trust the summaries they see in Dynamics.

From a practical standpoint, implement the solution using the tools at your disposal: InteractionSync's screen-pop and activity mapping, Genesys conversation attributes and Summaries API, and Dynamics CIF events or custom scripting. Always fail safe – if something isn't right (no context, or context changed), err on the side of not pushing the summary automatically. It's better to have an agent manually intervene in an edge case than to have a summary attached to the wrong account. Finally, continuously monitor and refine the process. As Genesys and Microsoft update their integrations (for example, adding native support for summary injection in future releases), adapt your strategy to take advantage of those while keeping the fundamental requirement in mind: each summary goes to the one and only correct member record.

By following these best practices, Genesys Cloud administrators and developers can confidently deploy Agent Co-Pilot summarization in tandem with Dynamics 365, knowing that the right information will reach the right customer record every time. Your CRM will remain clean and accurate, and your agents will gain efficiency from AI summaries without introducing risk.

Thank you, Leor!

Hi Alex,

First - wow! Thank you for the detailed idea. It would be great to break this up into a few components and add to our Idea Hub. I can track and note there.

There are two features that are upcoming that could be used as a workaround. The first is on-demand summaries and the second is setting the Time-To-Live for generated summaries. 

On-demand would allow you to generate a summary during a call with an agent. This way, you could potentially check where you want the summary stored and then set an action close to the end of the interaction to generate the summary via API. 

Time-to-live would allow you to delete summaries for a particular queue so they aren't stored unless you save them where specified within the time-to-live period (minimum being two hours). 

While these two features could be used to cobble together a solution, it would be easier if we were to implement more configurations are who, when, and how a summary is generated. Will be taking this into consideration for our next updates.

Very grateful!

Leor

Tightly Binding Agent Co-Pilot Summaries to the Correct D365 Member Account

Introduction

Genesys Cloud's Agent Co-Pilot can automatically generate a summary of each customer interaction, which is extremely useful for after-call work. However, when integrating with Microsoft Dynamics 365 (D365), it's critical to ensure these AI-generated summaries are only pushed to the correct member's account record. If a summary is attached to the wrong account, it can lead to serious data integrity and privacy issues (often called cross-account contamination). The goal is to tightly bind the Co-Pilot summarization lifecycle – from start through push – to the active D365 customer context. In practice, this means the Co-Pilot summary process must be context-aware and only operate when an agent has a confirmed D365 member record open for the interaction. Genesys Cloud does support querying and exporting conversation summaries via API for CRM integration[1], but it's up to administrators and developers to implement the proper safeguards so summaries go to the right place. Below we outline the functional requirements and best practices for achieving this binding.

Key Functional Requirements

To guarantee that Co-Pilot summaries are linked to the correct Dynamics account, the following requirements must be met:

·       Context before Summarization: Summarization must not begin until a Dynamics 365 member account record is actively open/identified. In other words, Co-Pilot's auto-summary should only activate after the agent is viewing a confirmed customer record in D365. If an interaction isn't yet tied to a CRM contact/lead/account, the summarization feature should remain idle (or in a paused state).

·       No Context = No Summaries: If no D365 member record is open, Co-Pilot should not generate or display a summary. The system should effectively prevent or delay any auto-summarization when the CRM context is missing. This ensures you don't produce a summary that might accidentally be saved to the wrong place or require manual handling.

·       Validated Member for Push: When the call ends, push the summary to D365 only if a valid, active member record has been confirmed for that interaction. The integration must double-check that the conversation is associated with a specific Dynamics contact/account before transferring the summary text. If the CRM context was never set (or was lost), the summary should not be auto-sent into D365.

·       Reset on Session Change: If the agent closes the current member's session or switches to a different account record mid-interaction, the summarization process should reset. Any ongoing or pending summarization tied to the previous context should be cleared or halted to avoid mixing content between accounts. Essentially, Co-Pilot's summary lifecycle should be tightly scoped to one CRM session – when the agent moves to another customer or a new session, it should treat it as a fresh start.

·       Explicit Lifecycle Controls: Provide clear controls or hooks for "start, stop, push, reset" that are triggered by D365 context events. In practice, this means your integration or custom code should listen for events like record opened, record closed, record changed, and invoke the appropriate summarization control:

·       Start when a D365 member context is established (e.g. agent has an active contact open).

·       Stop/Pause if the context is removed or unknown (e.g. agent navigates away or no contact selected).

·       Push when ready to send the final summary to CRM (e.g. on call completion, if context is valid).

·       Reset when the session ends or the agent switches context (clearing any state so the next interaction starts cleanly).

These requirements enforce that an Agent Co-Pilot summary is always explicitly linked to a single, correct Dynamics 365 member record throughout its creation and delivery.

Implementing a Context-Bound Summarization Lifecycle

Meeting the above requirements involves configuring the Genesys–D365 integration and possibly adding custom logic. Below are best practices and implementation guidelines to tightly bind the summarization lifecycle to the CRM context:

• 1. Establish CRM Context Before Summarization: Leverage Genesys Cloud's integration (InteractionSync for D365) to identify and lock in the customer context at the start of the call. InteractionSync will typically do an automated screen-pop in Dynamics, searching for the incoming caller's record and opening it for the agent[2]. It also automatically creates a Dynamics activity (e.g. Phone Call record) for the interaction and associates it to the found contact/lead/account[2]. This means as soon as the call begins (and the caller is identified), there is a specific CRM record tied to the interaction. Ensure this screen-pop and activity creation is working reliably for your queues (configure the integration's lookup logic so that it finds the correct member by phone number or other identifiers). If the integration cannot find a match and the agent must search manually, make it a standard operating procedure that the agent selects or creates the correct member record before proceeding further. In summary: do not let the call progress to wrap-up or summary generation without an attached CRM context. This is the foundation – the Co-Pilot summary feature needs that "anchor" to a Dynamics record.
• 2. Gating Auto-Summarization on Context: Out-of-the-box, Agent Co-Pilot will generate a summary when an interaction is completed (disconnected) as long as the feature is enabled for that interaction type[3][4]. You can't truly "stop" Co-Pilot from attempting to summarize a conversation it handled – but you can gate whether that summary gets used or pushed to CRM. One strategy is to configure Co-Pilot or your business rules such that summarization is expected only in certain scenarios (for example, enable Co-Pilot on queues or interactions that are likely to have an identified customer). If an interaction ends and no Dynamics record was ever opened (meaning the call remained anonymous), simply do not transfer the summary anywhere. It will exist in Genesys for a brief period (by design, Co-Pilot summaries are stored for 10 days internally[5]), but your integration should treat it as a no-op in terms of CRM. In effect, Co-Pilot is "paused" waiting for a valid customer context. As soon as the agent does identify/open a member record (even if mid-call), that event can serve as the green light to resume or consider summarization active. If your integration is capable, you might even programmatically trigger the summary generation at that moment (e.g. by calling the summarization API at call end, once context is confirmed). The key is that no summary leaves Genesys Cloud unless a member context is set.
• 3. Hooking into Context Changes (Start/Stop): It's important to tie into the events of your CRM UI so you know when an agent has opened or closed a member's record. In Dynamics 365 (especially with the multi-session interface for Customer Service), each session/tab corresponds to a customer issue or account context. The Genesys integration can be extended via the Dynamics Channel Integration Framework (CIF) or client-side scripts to detect when a new session starts or ends. For example:

·       When a screen pop occurs and opens a contact, have that trigger a "Start Summarization" event in your logic. This could be as simple as setting a flag in the Genesys conversation's participant data that "CRM Context = [ContactID] established", or enabling a timer/collection of transcript for summary. From this point, Co-Pilot can continue transcribing and later summarizing, confident there's an associated account.

·       If the agent closes the contact tab or Dynamics session before the call is over (intentionally or accidentally), catch that event to "Pause Summarization." In practice, you might set a flag like "context lost" which tells your post-call routine not to push any summary. You could even alert the agent or require them to re-open the member record. This prevents a scenario where a summary is generated with nowhere in CRM to go.

·       If the agent switches to a different account record during the call (for instance, they realized the initial screen-pop was the wrong John Smith and they pulled up a different John Smith's record), then you should treat that similar to closing one context and starting another. In other words, reset the summarization binding – mark the old context as inactive and the new one as the official context. Technically, the conversation's transcript is continuous, but by resetting and re-binding to the new record, you ensure the final summary will be linked to the correct customer. (If your integration created an activity on the first record, you may need to update it or create a new one on the correct record – the Dynamics "regarding" field of the Phone Call can be changed to the new contact if needed so that all notes and the summary ultimately relate to the right person.)

• Some Genesys–CRM integrations also support an "Associations" feature in the agent's call log, which allows manually re-linking an interaction to a different CRM entity if needed. If your agents use that, tie your summarization logic to the final association they set. Essentially, always refer to the current associated member record when deciding where to send the summary.
• 4. Pushing the Summary to D365 (Finalize on Call End): The actual handoff of the summary to Dynamics should occur at the end of the call, during the after-call work (ACW) phase or immediately after. This is when Genesys Co-Pilot presents the generated summary to the agent in the interface[3]. At this point, your integration or custom process should do a final check: "Do we have a valid Dynamics member ID for this conversation?" If yes, proceed to push; if not, skip it. Pushing the summary can be accomplished in a couple of ways:

·       Manual method: The agent can copy the Co-Pilot summary text from Genesys and paste it into the call notes or a custom field in the Genesys sidebar, which will sync to the Dynamics activity. (As of mid-2024, this was the primary method – Genesys confirmed that Co-Pilot summarization for D365 requires a manual copy/paste into the wrap-up notes field[6].) While this works, it relies on agent diligence and is prone to error if the agent has the wrong record open. You should train agents to double-check the CRM tab before pasting the summary.

·       Automated method: A more robust approach is to use Genesys Cloud's APIs and Data Actions to transfer the summary directly. Genesys provides a Conversation Summaries API which allows you to retrieve the AI-generated summary programmatically[1]. Your integration can call GET /api/v2/conversations/{conversationId}/summaries (with appropriate authorization) once the call is complete to obtain the summary text and any AI-suggested fields (like reason or resolution). Then, using a Genesys Data Action or a custom service, push that summary into Dynamics. For example, you could update the Phone Call activity's description or add a note to the contact's timeline with the summary text. This automation eliminates copy/paste mistakes. Important: Do this only if conversationId is reliably tied to a Dynamics record. You might use a custom conversation attribute or the activity's CRM ID to correlate – for instance, InteractionSync can store Genesys Conversation ID on the Dynamics activity record[7][8]. By using such an identifier, your code can ensure it's updating the correct Dynamics record with the summary.

• In either case, make sure the Dynamics record is still active/valid at push time. If the agent had closed the CRM tab or if the integration did not find any contact, your push logic should detect that and refrain from sending. It's better to have a summary stay in Genesys (where it expires in 10 days) than to accidentally attach it to the wrong customer in D365.
• 5. Resetting Between Sessions: Each interaction (call/chat/etc.) should be treated as a separate summarization session tied to its own CRM context. Once an interaction is fully completed and the summary has (or hasn't) been pushed, you should reset any tracking variables or context flags in your integration layer. The next call an agent handles will likely pertain to a different account, so your logic should start fresh (waiting for a new screen-pop and context establishment). Genesys Cloud's Agent Co-Pilot will naturally separate summaries by conversation ID, so there's no data overlap on Genesys' side. Your job is to mirror that separation in the CRM integration. For example, if you were storing the current Dynamics record ID in a variable during the call, clear it out at call end. This prevents any chance that a new call could accidentally reuse a previous call's context. Also ensure the Genesys UI is reset – typically, the integration will open a new Dynamics activity for the next call, but if an agent manually stayed on an old record, be cautious. It is a best practice to navigate away from the last contact's screen after finishing ACW, or let the integration auto-pop the next one, so that the visible CRM context always matches the active interaction. The Genesys InteractionSync release notes even highlight multi-session management considerations (for example, a known issue was that if an agent opened a record via search rather than the screen-pop, a session ID wasn't generated[9], which could complicate context tracking). Being aware of such limitations, make sure to test and enforce context continuity between Genesys and D365 at the start and end of sessions.

By following the above practices, you effectively create a mechanism where Co-Pilot's summarization is contextually aware of the Dynamics 365 member session. The summary generation might be an automated AI feature, but you are wrapping it in rules that tie it to Dynamics' state: it "starts" when a customer is identified, it "stops" if the customer context is lost, it only "pushes" upon a valid conclusion with the correct customer, and it "resets" when moving to a new session.

Avoiding Cross-Account Contamination

A primary risk in any CRM-integrated summarization is that a summary from one customer interaction ends up attached to a different customer's record. Here are some best practices to prevent this "cross-account contamination":

·       Enforce One-Conversation/One-Record Linking: Ensure that each Genesys conversation ID is linked to at most one Dynamics record. If your agent tries to handle multiple accounts in one call (e.g. the caller asks about two different people's info – a rare but possible scenario), do not attempt to use one summary for both. Instead, the agent should split the call or notes accordingly. The integration should log the call under one primary contact or case in Dynamics. By keeping this one-to-one mapping, you eliminate ambiguity about where the summary should go.

·       Don't Share Summary Content Across Accounts: Never copy a summary from one member's activity into another's. If information from a call needs to be noted on two accounts (for instance, a conference call involving two clients), it's better to have the agent write separate notes for the second account manually. The Co-Pilot summary is tailored to the single interaction and should remain attached only to the records that were part of that interaction.

·       Use Unique Identifiers for Verification: As mentioned, leverage identifiers like the Genesys conversation ID or the Dynamics activity ID to track the linkage. Many organizations add a custom field in D365 for "Genesys Conversation ID" and populate it for each call activity[7]. This allows you to later audit where a summary was attached. If you ever see the same conversation ID on two different contact records, that's a red flag.

·       Train Agents on the Integration Workflow: Sometimes contamination happens due to human error – e.g. an agent might forget to switch the CRM record when a caller reveals new information ("Actually, I'm calling about my spouse's account, not mine"). Make sure agents know to update the CRM context ASAP in such cases (perhaps using the "Associations" feature to relink the call if needed). If they do that, your integration logic (start/stop/reset as discussed) should handle the rest – but the agent's awareness is the first line of defense.

·       Handle Multi-Tab Concurrency Carefully: If your agents can have multiple customer sessions open concurrently (for example, handling two chats at once with two different members), verify that the Genesys integration truly sandboxes each session. Co-Pilot should be running separately for each conversation. The risk here is lower because Genesys Cloud will generate two distinct summaries for two distinct interactions, but ensure your UI makes it clear which summary belongs to which session. Dynamics 365's multi-session interface usually keeps activities separated by tabs, and each Genesys interaction is associated with the correct tab when using the official integration. Still, it's wise to test this: have an agent handle two interactions and confirm that each Dynamics activity gets the correct notes and summary.

·       Monitor and Log Summary Pushes: Implement logging around the summary push operation. For example, if using a custom Data Action to send the summary to D365, log the conversation ID, target CRM entity, and timestamp. This way, if anything does go awry, you can trace it. Regularly review a few records to ensure summaries are appearing where they should.

·       Beware of "Stale" CRM Context: A common edge-case: the agent ends a call but leaves the Dynamics tab open on that contact, then later takes a new call and forgets that the old tab is still open. If your integration doesn't automatically pop a new tab (say the new call comes in unknown and doesn't pop), the agent might inadvertently paste a summary into the wrong contact's notes. To mitigate this, configure the integration to either always open a new session for each interaction (preferred), or have agents close out old sessions. Some integrations will auto-focus the relevant tab or update it; ensure that behavior is working. Using the session reset best practice from earlier (clearing context between calls) will help avoid this scenario.

In short, maintaining a strong binding between the conversation and the CRM record throughout the call prevents leakage of data across accounts. Each context change is an opportunity to either reinforce the correct link or to halt summarization until the link is corrected.

Verification and Testing

Implementing these controls is only half the battle – you'll want to rigorously test the summarization lifecycle to be confident it behaves as expected. Here are recommended techniques for verification:

·       Simulate Normal Calls: Place test calls where the caller matches exactly one Dynamics contact (or member account). Ensure the integration screen-pops that contact, the call logs to that contact's record, and when the call ends, the Co-Pilot summary appears only on that contact's timeline or activity. Verify that the summary content in D365 matches what Genesys Co-Pilot displayed. This tests the happy path end-to-end.

·       Test No-Context Scenario: Simulate a call from an unknown number that isn't in D365. The integration likely will not pop a contact (it might open a blank search or "new contact" form). Do not select or create any contact – let the call conclude without an associated record. The expectation: Co-Pilot may still generate a summary in the Genesys UI for the agent's reference, but no summary or call activity should appear in Dynamics. Check that no activity was inadvertently created, or if one was (some systems log the call to a generic record), confirm its notes are empty. Essentially, confirm that your "no context, no push" rule is honored.

·       Test Context Gained Mid-Call: Start a call with no initial CRM match, then during the call have the agent manually find and open the correct member record (perhaps the caller provides an email or account number that allows a manual search). Ensure that once the record is open, the rest of the call is logged under that record. When the call ends, the summary should be pushed to that newly selected record's activity. Check that the summary did attach to it, and nowhere else. This verifies that your late-binding of context still triggers the summary push correctly.

·       Test Context Switch Mid-Call: More complex: use a scenario where the wrong contact pops first. For example, two contacts with the same name and your integration pops the first one. Have the agent realize the mistake and switch to the second contact's record while on the call. After call completion, verify that the summary went to the second (correct) contact's record and that the first contact's record (which was initially opened) does not have any summary or has the activity reassigned. This is a crucial test for the "switch and reset" logic.

·       Concurrent Interactions: If applicable, have an agent handle two interactions concurrently (if your business allows, e.g. a voice call and a chat, or two chats). Confirm that two separate summaries are generated and each is pushed to the appropriate Dynamics record. The agent's interface should clearly separate the two (Dynamics will have two activities in two sessions). This test ensures no overlap in multi-tasking scenarios.

·       Long Calls and Edge Cases: Test a long call (over 30-40 minutes) to ensure summarization still functions (Genesys summarization might not produce output if conversation exceeds certain lengths[10]). Also test calls that transfer between agents: if your workflow involves transfers, ensure that when Agent A transfers to Agent B, the summary of Agent A's portion goes to the correct record and Agent B's summary goes to the correct record. (Out of the box, each agent gets their own summary for their portion[11][12]. In a CRM context, both parts should ideally log to the same customer's history – make sure your integration doesn't open a new contact for the second agent erroneously.)

·       Review Audit Trails: After testing, review the Dynamics records and Genesys conversation details. Check that each Dynamics activity has the right Genesys conversation ID (if you map it) and that it matches the conversation where the summary came from. Utilize Genesys's analytics or quality tools to cross-verify content if needed. Also consider enabling debug logging in InteractionSync (Genesys integration) during testing; it can show events like screen-pop, association changes, etc., which help confirm your "start/stop" hooks fired correctly.

By performing the above tests, you can be confident that Agent Co-Pilot summaries are being handled in a controlled, context-sensitive manner. Any discrepancies found should be addressed by refining the integration logic or user procedure before going live.

Conclusion

In a Genesys Cloud + Microsoft Dynamics 365 environment, tying AI summaries to the correct member account is essential for data accuracy, security, and usefulness. The Genesys Agent Co-Pilot feature is powerful, but without the proper context binding, its summaries could end up in the wrong place or at the wrong time. By enforcing that a valid D365 member session is in place for every summary, and by using lifecycle hooks to start, stop, push, or reset summarization based on CRM context, you create a tight coupling between the conversation and the CRM record. This not only prevents cross-account contamination of notes, but also ensures agents and supervisors can trust the summaries they see in Dynamics.

From a practical standpoint, implement the solution using the tools at your disposal: InteractionSync's screen-pop and activity mapping, Genesys conversation attributes and Summaries API, and Dynamics CIF events or custom scripting. Always fail safe – if something isn't right (no context, or context changed), err on the side of not pushing the summary automatically. It's better to have an agent manually intervene in an edge case than to have a summary attached to the wrong account. Finally, continuously monitor and refine the process. As Genesys and Microsoft update their integrations (for example, adding native support for summary injection in future releases), adapt your strategy to take advantage of those while keeping the fundamental requirement in mind: each summary goes to the one and only correct member record.

By following these best practices, Genesys Cloud administrators and developers can confidently deploy Agent Co-Pilot summarization in tandem with Dynamics 365, knowing that the right information will reach the right customer record every time. Your CRM will remain clean and accurate, and your agents will gain efficiency from AI summaries without introducing risk.

Hi Alex,

First - wow! Thank you for the detailed idea. It would be great to break this up into a few components and add to our Idea Hub. I can track and note there.

There are two features that are upcoming that could be used as a workaround. The first is on-demand summaries and the second is setting the Time-To-Live for generated summaries. 

On-demand would allow you to generate a summary during a call with an agent. This way, you could potentially check where you want the summary stored and then set an action close to the end of the interaction to generate the summary via API. 

Time-to-live would allow you to delete summaries for a particular queue so they aren't stored unless you save them where specified within the time-to-live period (minimum being two hours). 

While these two features could be used to cobble together a solution, it would be easier if we were to implement more configurations are who, when, and how a summary is generated. Will be taking this into consideration for our next updates.

Very grateful!

Leor

Tightly Binding Agent Co-Pilot Summaries to the Correct D365 Member Account

Introduction

Genesys Cloud's Agent Co-Pilot can automatically generate a summary of each customer interaction, which is extremely useful for after-call work. However, when integrating with Microsoft Dynamics 365 (D365), it's critical to ensure these AI-generated summaries are only pushed to the correct member's account record. If a summary is attached to the wrong account, it can lead to serious data integrity and privacy issues (often called cross-account contamination). The goal is to tightly bind the Co-Pilot summarization lifecycle – from start through push – to the active D365 customer context. In practice, this means the Co-Pilot summary process must be context-aware and only operate when an agent has a confirmed D365 member record open for the interaction. Genesys Cloud does support querying and exporting conversation summaries via API for CRM integration[1], but it's up to administrators and developers to implement the proper safeguards so summaries go to the right place. Below we outline the functional requirements and best practices for achieving this binding.

Key Functional Requirements

To guarantee that Co-Pilot summaries are linked to the correct Dynamics account, the following requirements must be met:

·       Context before Summarization: Summarization must not begin until a Dynamics 365 member account record is actively open/identified. In other words, Co-Pilot's auto-summary should only activate after the agent is viewing a confirmed customer record in D365. If an interaction isn't yet tied to a CRM contact/lead/account, the summarization feature should remain idle (or in a paused state).

·       No Context = No Summaries: If no D365 member record is open, Co-Pilot should not generate or display a summary. The system should effectively prevent or delay any auto-summarization when the CRM context is missing. This ensures you don't produce a summary that might accidentally be saved to the wrong place or require manual handling.

·       Validated Member for Push: When the call ends, push the summary to D365 only if a valid, active member record has been confirmed for that interaction. The integration must double-check that the conversation is associated with a specific Dynamics contact/account before transferring the summary text. If the CRM context was never set (or was lost), the summary should not be auto-sent into D365.

·       Reset on Session Change: If the agent closes the current member's session or switches to a different account record mid-interaction, the summarization process should reset. Any ongoing or pending summarization tied to the previous context should be cleared or halted to avoid mixing content between accounts. Essentially, Co-Pilot's summary lifecycle should be tightly scoped to one CRM session – when the agent moves to another customer or a new session, it should treat it as a fresh start.

·       Explicit Lifecycle Controls: Provide clear controls or hooks for "start, stop, push, reset" that are triggered by D365 context events. In practice, this means your integration or custom code should listen for events like record opened, record closed, record changed, and invoke the appropriate summarization control:

·       Start when a D365 member context is established (e.g. agent has an active contact open).

·       Stop/Pause if the context is removed or unknown (e.g. agent navigates away or no contact selected).

·       Push when ready to send the final summary to CRM (e.g. on call completion, if context is valid).

·       Reset when the session ends or the agent switches context (clearing any state so the next interaction starts cleanly).

These requirements enforce that an Agent Co-Pilot summary is always explicitly linked to a single, correct Dynamics 365 member record throughout its creation and delivery.

Implementing a Context-Bound Summarization Lifecycle

Meeting the above requirements involves configuring the Genesys–D365 integration and possibly adding custom logic. Below are best practices and implementation guidelines to tightly bind the summarization lifecycle to the CRM context:

• 1. Establish CRM Context Before Summarization: Leverage Genesys Cloud's integration (InteractionSync for D365) to identify and lock in the customer context at the start of the call. InteractionSync will typically do an automated screen-pop in Dynamics, searching for the incoming caller's record and opening it for the agent[2]. It also automatically creates a Dynamics activity (e.g. Phone Call record) for the interaction and associates it to the found contact/lead/account[2]. This means as soon as the call begins (and the caller is identified), there is a specific CRM record tied to the interaction. Ensure this screen-pop and activity creation is working reliably for your queues (configure the integration's lookup logic so that it finds the correct member by phone number or other identifiers). If the integration cannot find a match and the agent must search manually, make it a standard operating procedure that the agent selects or creates the correct member record before proceeding further. In summary: do not let the call progress to wrap-up or summary generation without an attached CRM context. This is the foundation – the Co-Pilot summary feature needs that "anchor" to a Dynamics record.
• 2. Gating Auto-Summarization on Context: Out-of-the-box, Agent Co-Pilot will generate a summary when an interaction is completed (disconnected) as long as the feature is enabled for that interaction type[3][4]. You can't truly "stop" Co-Pilot from attempting to summarize a conversation it handled – but you can gate whether that summary gets used or pushed to CRM. One strategy is to configure Co-Pilot or your business rules such that summarization is expected only in certain scenarios (for example, enable Co-Pilot on queues or interactions that are likely to have an identified customer). If an interaction ends and no Dynamics record was ever opened (meaning the call remained anonymous), simply do not transfer the summary anywhere. It will exist in Genesys for a brief period (by design, Co-Pilot summaries are stored for 10 days internally[5]), but your integration should treat it as a no-op in terms of CRM. In effect, Co-Pilot is "paused" waiting for a valid customer context. As soon as the agent does identify/open a member record (even if mid-call), that event can serve as the green light to resume or consider summarization active. If your integration is capable, you might even programmatically trigger the summary generation at that moment (e.g. by calling the summarization API at call end, once context is confirmed). The key is that no summary leaves Genesys Cloud unless a member context is set.
• 3. Hooking into Context Changes (Start/Stop): It's important to tie into the events of your CRM UI so you know when an agent has opened or closed a member's record. In Dynamics 365 (especially with the multi-session interface for Customer Service), each session/tab corresponds to a customer issue or account context. The Genesys integration can be extended via the Dynamics Channel Integration Framework (CIF) or client-side scripts to detect when a new session starts or ends. For example:

·       When a screen pop occurs and opens a contact, have that trigger a "Start Summarization" event in your logic. This could be as simple as setting a flag in the Genesys conversation's participant data that "CRM Context = [ContactID] established", or enabling a timer/collection of transcript for summary. From this point, Co-Pilot can continue transcribing and later summarizing, confident there's an associated account.

·       If the agent closes the contact tab or Dynamics session before the call is over (intentionally or accidentally), catch that event to "Pause Summarization." In practice, you might set a flag like "context lost" which tells your post-call routine not to push any summary. You could even alert the agent or require them to re-open the member record. This prevents a scenario where a summary is generated with nowhere in CRM to go.

·       If the agent switches to a different account record during the call (for instance, they realized the initial screen-pop was the wrong John Smith and they pulled up a different John Smith's record), then you should treat that similar to closing one context and starting another. In other words, reset the summarization binding – mark the old context as inactive and the new one as the official context. Technically, the conversation's transcript is continuous, but by resetting and re-binding to the new record, you ensure the final summary will be linked to the correct customer. (If your integration created an activity on the first record, you may need to update it or create a new one on the correct record – the Dynamics "regarding" field of the Phone Call can be changed to the new contact if needed so that all notes and the summary ultimately relate to the right person.)

• Some Genesys–CRM integrations also support an "Associations" feature in the agent's call log, which allows manually re-linking an interaction to a different CRM entity if needed. If your agents use that, tie your summarization logic to the final association they set. Essentially, always refer to the current associated member record when deciding where to send the summary.
• 4. Pushing the Summary to D365 (Finalize on Call End): The actual handoff of the summary to Dynamics should occur at the end of the call, during the after-call work (ACW) phase or immediately after. This is when Genesys Co-Pilot presents the generated summary to the agent in the interface[3]. At this point, your integration or custom process should do a final check: "Do we have a valid Dynamics member ID for this conversation?" If yes, proceed to push; if not, skip it. Pushing the summary can be accomplished in a couple of ways:

·       Manual method: The agent can copy the Co-Pilot summary text from Genesys and paste it into the call notes or a custom field in the Genesys sidebar, which will sync to the Dynamics activity. (As of mid-2024, this was the primary method – Genesys confirmed that Co-Pilot summarization for D365 requires a manual copy/paste into the wrap-up notes field[6].) While this works, it relies on agent diligence and is prone to error if the agent has the wrong record open. You should train agents to double-check the CRM tab before pasting the summary.

·       Automated method: A more robust approach is to use Genesys Cloud's APIs and Data Actions to transfer the summary directly. Genesys provides a Conversation Summaries API which allows you to retrieve the AI-generated summary programmatically[1]. Your integration can call GET /api/v2/conversations/{conversationId}/summaries (with appropriate authorization) once the call is complete to obtain the summary text and any AI-suggested fields (like reason or resolution). Then, using a Genesys Data Action or a custom service, push that summary into Dynamics. For example, you could update the Phone Call activity's description or add a note to the contact's timeline with the summary text. This automation eliminates copy/paste mistakes. Important: Do this only if conversationId is reliably tied to a Dynamics record. You might use a custom conversation attribute or the activity's CRM ID to correlate – for instance, InteractionSync can store Genesys Conversation ID on the Dynamics activity record[7][8]. By using such an identifier, your code can ensure it's updating the correct Dynamics record with the summary.

• In either case, make sure the Dynamics record is still active/valid at push time. If the agent had closed the CRM tab or if the integration did not find any contact, your push logic should detect that and refrain from sending. It's better to have a summary stay in Genesys (where it expires in 10 days) than to accidentally attach it to the wrong customer in D365.
• 5. Resetting Between Sessions: Each interaction (call/chat/etc.) should be treated as a separate summarization session tied to its own CRM context. Once an interaction is fully completed and the summary has (or hasn't) been pushed, you should reset any tracking variables or context flags in your integration layer. The next call an agent handles will likely pertain to a different account, so your logic should start fresh (waiting for a new screen-pop and context establishment). Genesys Cloud's Agent Co-Pilot will naturally separate summaries by conversation ID, so there's no data overlap on Genesys' side. Your job is to mirror that separation in the CRM integration. For example, if you were storing the current Dynamics record ID in a variable during the call, clear it out at call end. This prevents any chance that a new call could accidentally reuse a previous call's context. Also ensure the Genesys UI is reset – typically, the integration will open a new Dynamics activity for the next call, but if an agent manually stayed on an old record, be cautious. It is a best practice to navigate away from the last contact's screen after finishing ACW, or let the integration auto-pop the next one, so that the visible CRM context always matches the active interaction. The Genesys InteractionSync release notes even highlight multi-session management considerations (for example, a known issue was that if an agent opened a record via search rather than the screen-pop, a session ID wasn't generated[9], which could complicate context tracking). Being aware of such limitations, make sure to test and enforce context continuity between Genesys and D365 at the start and end of sessions.

By following the above practices, you effectively create a mechanism where Co-Pilot's summarization is contextually aware of the Dynamics 365 member session. The summary generation might be an automated AI feature, but you are wrapping it in rules that tie it to Dynamics' state: it "starts" when a customer is identified, it "stops" if the customer context is lost, it only "pushes" upon a valid conclusion with the correct customer, and it "resets" when moving to a new session.

Avoiding Cross-Account Contamination

A primary risk in any CRM-integrated summarization is that a summary from one customer interaction ends up attached to a different customer's record. Here are some best practices to prevent this "cross-account contamination":

·       Enforce One-Conversation/One-Record Linking: Ensure that each Genesys conversation ID is linked to at most one Dynamics record. If your agent tries to handle multiple accounts in one call (e.g. the caller asks about two different people's info – a rare but possible scenario), do not attempt to use one summary for both. Instead, the agent should split the call or notes accordingly. The integration should log the call under one primary contact or case in Dynamics. By keeping this one-to-one mapping, you eliminate ambiguity about where the summary should go.

·       Don't Share Summary Content Across Accounts: Never copy a summary from one member's activity into another's. If information from a call needs to be noted on two accounts (for instance, a conference call involving two clients), it's better to have the agent write separate notes for the second account manually. The Co-Pilot summary is tailored to the single interaction and should remain attached only to the records that were part of that interaction.

·       Use Unique Identifiers for Verification: As mentioned, leverage identifiers like the Genesys conversation ID or the Dynamics activity ID to track the linkage. Many organizations add a custom field in D365 for "Genesys Conversation ID" and populate it for each call activity[7]. This allows you to later audit where a summary was attached. If you ever see the same conversation ID on two different contact records, that's a red flag.

·       Train Agents on the Integration Workflow: Sometimes contamination happens due to human error – e.g. an agent might forget to switch the CRM record when a caller reveals new information ("Actually, I'm calling about my spouse's account, not mine"). Make sure agents know to update the CRM context ASAP in such cases (perhaps using the "Associations" feature to relink the call if needed). If they do that, your integration logic (start/stop/reset as discussed) should handle the rest – but the agent's awareness is the first line of defense.

·       Handle Multi-Tab Concurrency Carefully: If your agents can have multiple customer sessions open concurrently (for example, handling two chats at once with two different members), verify that the Genesys integration truly sandboxes each session. Co-Pilot should be running separately for each conversation. The risk here is lower because Genesys Cloud will generate two distinct summaries for two distinct interactions, but ensure your UI makes it clear which summary belongs to which session. Dynamics 365's multi-session interface usually keeps activities separated by tabs, and each Genesys interaction is associated with the correct tab when using the official integration. Still, it's wise to test this: have an agent handle two interactions and confirm that each Dynamics activity gets the correct notes and summary.

·       Monitor and Log Summary Pushes: Implement logging around the summary push operation. For example, if using a custom Data Action to send the summary to D365, log the conversation ID, target CRM entity, and timestamp. This way, if anything does go awry, you can trace it. Regularly review a few records to ensure summaries are appearing where they should.

·       Beware of "Stale" CRM Context: A common edge-case: the agent ends a call but leaves the Dynamics tab open on that contact, then later takes a new call and forgets that the old tab is still open. If your integration doesn't automatically pop a new tab (say the new call comes in unknown and doesn't pop), the agent might inadvertently paste a summary into the wrong contact's notes. To mitigate this, configure the integration to either always open a new session for each interaction (preferred), or have agents close out old sessions. Some integrations will auto-focus the relevant tab or update it; ensure that behavior is working. Using the session reset best practice from earlier (clearing context between calls) will help avoid this scenario.

In short, maintaining a strong binding between the conversation and the CRM record throughout the call prevents leakage of data across accounts. Each context change is an opportunity to either reinforce the correct link or to halt summarization until the link is corrected.

Verification and Testing

Implementing these controls is only half the battle – you'll want to rigorously test the summarization lifecycle to be confident it behaves as expected. Here are recommended techniques for verification:

·       Simulate Normal Calls: Place test calls where the caller matches exactly one Dynamics contact (or member account). Ensure the integration screen-pops that contact, the call logs to that contact's record, and when the call ends, the Co-Pilot summary appears only on that contact's timeline or activity. Verify that the summary content in D365 matches what Genesys Co-Pilot displayed. This tests the happy path end-to-end.

·       Test No-Context Scenario: Simulate a call from an unknown number that isn't in D365. The integration likely will not pop a contact (it might open a blank search or "new contact" form). Do not select or create any contact – let the call conclude without an associated record. The expectation: Co-Pilot may still generate a summary in the Genesys UI for the agent's reference, but no summary or call activity should appear in Dynamics. Check that no activity was inadvertently created, or if one was (some systems log the call to a generic record), confirm its notes are empty. Essentially, confirm that your "no context, no push" rule is honored.

·       Test Context Gained Mid-Call: Start a call with no initial CRM match, then during the call have the agent manually find and open the correct member record (perhaps the caller provides an email or account number that allows a manual search). Ensure that once the record is open, the rest of the call is logged under that record. When the call ends, the summary should be pushed to that newly selected record's activity. Check that the summary did attach to it, and nowhere else. This verifies that your late-binding of context still triggers the summary push correctly.

·       Test Context Switch Mid-Call: More complex: use a scenario where the wrong contact pops first. For example, two contacts with the same name and your integration pops the first one. Have the agent realize the mistake and switch to the second contact's record while on the call. After call completion, verify that the summary went to the second (correct) contact's record and that the first contact's record (which was initially opened) does not have any summary or has the activity reassigned. This is a crucial test for the "switch and reset" logic.

·       Concurrent Interactions: If applicable, have an agent handle two interactions concurrently (if your business allows, e.g. a voice call and a chat, or two chats). Confirm that two separate summaries are generated and each is pushed to the appropriate Dynamics record. The agent's interface should clearly separate the two (Dynamics will have two activities in two sessions). This test ensures no overlap in multi-tasking scenarios.

·       Long Calls and Edge Cases: Test a long call (over 30-40 minutes) to ensure summarization still functions (Genesys summarization might not produce output if conversation exceeds certain lengths[10]). Also test calls that transfer between agents: if your workflow involves transfers, ensure that when Agent A transfers to Agent B, the summary of Agent A's portion goes to the correct record and Agent B's summary goes to the correct record. (Out of the box, each agent gets their own summary for their portion[11][12]. In a CRM context, both parts should ideally log to the same customer's history – make sure your integration doesn't open a new contact for the second agent erroneously.)

·       Review Audit Trails: After testing, review the Dynamics records and Genesys conversation details. Check that each Dynamics activity has the right Genesys conversation ID (if you map it) and that it matches the conversation where the summary came from. Utilize Genesys's analytics or quality tools to cross-verify content if needed. Also consider enabling debug logging in InteractionSync (Genesys integration) during testing; it can show events like screen-pop, association changes, etc., which help confirm your "start/stop" hooks fired correctly.

By performing the above tests, you can be confident that Agent Co-Pilot summaries are being handled in a controlled, context-sensitive manner. Any discrepancies found should be addressed by refining the integration logic or user procedure before going live.

Conclusion

In a Genesys Cloud + Microsoft Dynamics 365 environment, tying AI summaries to the correct member account is essential for data accuracy, security, and usefulness. The Genesys Agent Co-Pilot feature is powerful, but without the proper context binding, its summaries could end up in the wrong place or at the wrong time. By enforcing that a valid D365 member session is in place for every summary, and by using lifecycle hooks to start, stop, push, or reset summarization based on CRM context, you create a tight coupling between the conversation and the CRM record. This not only prevents cross-account contamination of notes, but also ensures agents and supervisors can trust the summaries they see in Dynamics.

From a practical standpoint, implement the solution using the tools at your disposal: InteractionSync's screen-pop and activity mapping, Genesys conversation attributes and Summaries API, and Dynamics CIF events or custom scripting. Always fail safe – if something isn't right (no context, or context changed), err on the side of not pushing the summary automatically. It's better to have an agent manually intervene in an edge case than to have a summary attached to the wrong account. Finally, continuously monitor and refine the process. As Genesys and Microsoft update their integrations (for example, adding native support for summary injection in future releases), adapt your strategy to take advantage of those while keeping the fundamental requirement in mind: each summary goes to the one and only correct member record.

By following these best practices, Genesys Cloud administrators and developers can confidently deploy Agent Co-Pilot summarization in tandem with Dynamics 365, knowing that the right information will reach the right customer record every time. Your CRM will remain clean and accurate, and your agents will gain efficiency from AI summaries without introducing risk.

Hi Alex,

First - wow! Thank you for the detailed idea. It would be great to break this up into a few components and add to our Idea Hub. I can track and note there.

There are two features that are upcoming that could be used as a workaround. The first is on-demand summaries and the second is setting the Time-To-Live for generated summaries. 

On-demand would allow you to generate a summary during a call with an agent. This way, you could potentially check where you want the summary stored and then set an action close to the end of the interaction to generate the summary via API. 

Time-to-live would allow you to delete summaries for a particular queue so they aren't stored unless you save them where specified within the time-to-live period (minimum being two hours). 

While these two features could be used to cobble together a solution, it would be easier if we were to implement more configurations are who, when, and how a summary is generated. Will be taking this into consideration for our next updates.

Very grateful!

Leor

Tightly Binding Agent Co-Pilot Summaries to the Correct D365 Member Account

Introduction

Genesys Cloud's Agent Co-Pilot can automatically generate a summary of each customer interaction, which is extremely useful for after-call work. However, when integrating with Microsoft Dynamics 365 (D365), it's critical to ensure these AI-generated summaries are only pushed to the correct member's account record. If a summary is attached to the wrong account, it can lead to serious data integrity and privacy issues (often called cross-account contamination). The goal is to tightly bind the Co-Pilot summarization lifecycle – from start through push – to the active D365 customer context. In practice, this means the Co-Pilot summary process must be context-aware and only operate when an agent has a confirmed D365 member record open for the interaction. Genesys Cloud does support querying and exporting conversation summaries via API for CRM integration[1], but it's up to administrators and developers to implement the proper safeguards so summaries go to the right place. Below we outline the functional requirements and best practices for achieving this binding.

Key Functional Requirements

To guarantee that Co-Pilot summaries are linked to the correct Dynamics account, the following requirements must be met:

·       Context before Summarization: Summarization must not begin until a Dynamics 365 member account record is actively open/identified. In other words, Co-Pilot's auto-summary should only activate after the agent is viewing a confirmed customer record in D365. If an interaction isn't yet tied to a CRM contact/lead/account, the summarization feature should remain idle (or in a paused state).

·       No Context = No Summaries: If no D365 member record is open, Co-Pilot should not generate or display a summary. The system should effectively prevent or delay any auto-summarization when the CRM context is missing. This ensures you don't produce a summary that might accidentally be saved to the wrong place or require manual handling.

·       Validated Member for Push: When the call ends, push the summary to D365 only if a valid, active member record has been confirmed for that interaction. The integration must double-check that the conversation is associated with a specific Dynamics contact/account before transferring the summary text. If the CRM context was never set (or was lost), the summary should not be auto-sent into D365.

·       Reset on Session Change: If the agent closes the current member's session or switches to a different account record mid-interaction, the summarization process should reset. Any ongoing or pending summarization tied to the previous context should be cleared or halted to avoid mixing content between accounts. Essentially, Co-Pilot's summary lifecycle should be tightly scoped to one CRM session – when the agent moves to another customer or a new session, it should treat it as a fresh start.

·       Explicit Lifecycle Controls: Provide clear controls or hooks for "start, stop, push, reset" that are triggered by D365 context events. In practice, this means your integration or custom code should listen for events like record opened, record closed, record changed, and invoke the appropriate summarization control:

·       Start when a D365 member context is established (e.g. agent has an active contact open).

·       Stop/Pause if the context is removed or unknown (e.g. agent navigates away or no contact selected).

·       Push when ready to send the final summary to CRM (e.g. on call completion, if context is valid).

·       Reset when the session ends or the agent switches context (clearing any state so the next interaction starts cleanly).

These requirements enforce that an Agent Co-Pilot summary is always explicitly linked to a single, correct Dynamics 365 member record throughout its creation and delivery.

Implementing a Context-Bound Summarization Lifecycle

Meeting the above requirements involves configuring the Genesys–D365 integration and possibly adding custom logic. Below are best practices and implementation guidelines to tightly bind the summarization lifecycle to the CRM context:

• 1. Establish CRM Context Before Summarization: Leverage Genesys Cloud's integration (InteractionSync for D365) to identify and lock in the customer context at the start of the call. InteractionSync will typically do an automated screen-pop in Dynamics, searching for the incoming caller's record and opening it for the agent[2]. It also automatically creates a Dynamics activity (e.g. Phone Call record) for the interaction and associates it to the found contact/lead/account[2]. This means as soon as the call begins (and the caller is identified), there is a specific CRM record tied to the interaction. Ensure this screen-pop and activity creation is working reliably for your queues (configure the integration's lookup logic so that it finds the correct member by phone number or other identifiers). If the integration cannot find a match and the agent must search manually, make it a standard operating procedure that the agent selects or creates the correct member record before proceeding further. In summary: do not let the call progress to wrap-up or summary generation without an attached CRM context. This is the foundation – the Co-Pilot summary feature needs that "anchor" to a Dynamics record.
• 2. Gating Auto-Summarization on Context: Out-of-the-box, Agent Co-Pilot will generate a summary when an interaction is completed (disconnected) as long as the feature is enabled for that interaction type[3][4]. You can't truly "stop" Co-Pilot from attempting to summarize a conversation it handled – but you can gate whether that summary gets used or pushed to CRM. One strategy is to configure Co-Pilot or your business rules such that summarization is expected only in certain scenarios (for example, enable Co-Pilot on queues or interactions that are likely to have an identified customer). If an interaction ends and no Dynamics record was ever opened (meaning the call remained anonymous), simply do not transfer the summary anywhere. It will exist in Genesys for a brief period (by design, Co-Pilot summaries are stored for 10 days internally[5]), but your integration should treat it as a no-op in terms of CRM. In effect, Co-Pilot is "paused" waiting for a valid customer context. As soon as the agent does identify/open a member record (even if mid-call), that event can serve as the green light to resume or consider summarization active. If your integration is capable, you might even programmatically trigger the summary generation at that moment (e.g. by calling the summarization API at call end, once context is confirmed). The key is that no summary leaves Genesys Cloud unless a member context is set.
• 3. Hooking into Context Changes (Start/Stop): It's important to tie into the events of your CRM UI so you know when an agent has opened or closed a member's record. In Dynamics 365 (especially with the multi-session interface for Customer Service), each session/tab corresponds to a customer issue or account context. The Genesys integration can be extended via the Dynamics Channel Integration Framework (CIF) or client-side scripts to detect when a new session starts or ends. For example:

·       When a screen pop occurs and opens a contact, have that trigger a "Start Summarization" event in your logic. This could be as simple as setting a flag in the Genesys conversation's participant data that "CRM Context = [ContactID] established", or enabling a timer/collection of transcript for summary. From this point, Co-Pilot can continue transcribing and later summarizing, confident there's an associated account.

·       If the agent closes the contact tab or Dynamics session before the call is over (intentionally or accidentally), catch that event to "Pause Summarization." In practice, you might set a flag like "context lost" which tells your post-call routine not to push any summary. You could even alert the agent or require them to re-open the member record. This prevents a scenario where a summary is generated with nowhere in CRM to go.

·       If the agent switches to a different account record during the call (for instance, they realized the initial screen-pop was the wrong John Smith and they pulled up a different John Smith's record), then you should treat that similar to closing one context and starting another. In other words, reset the summarization binding – mark the old context as inactive and the new one as the official context. Technically, the conversation's transcript is continuous, but by resetting and re-binding to the new record, you ensure the final summary will be linked to the correct customer. (If your integration created an activity on the first record, you may need to update it or create a new one on the correct record – the Dynamics "regarding" field of the Phone Call can be changed to the new contact if needed so that all notes and the summary ultimately relate to the right person.)

• Some Genesys–CRM integrations also support an "Associations" feature in the agent's call log, which allows manually re-linking an interaction to a different CRM entity if needed. If your agents use that, tie your summarization logic to the final association they set. Essentially, always refer to the current associated member record when deciding where to send the summary.
• 4. Pushing the Summary to D365 (Finalize on Call End): The actual handoff of the summary to Dynamics should occur at the end of the call, during the after-call work (ACW) phase or immediately after. This is when Genesys Co-Pilot presents the generated summary to the agent in the interface[3]. At this point, your integration or custom process should do a final check: "Do we have a valid Dynamics member ID for this conversation?" If yes, proceed to push; if not, skip it. Pushing the summary can be accomplished in a couple of ways:

·       Manual method: The agent can copy the Co-Pilot summary text from Genesys and paste it into the call notes or a custom field in the Genesys sidebar, which will sync to the Dynamics activity. (As of mid-2024, this was the primary method – Genesys confirmed that Co-Pilot summarization for D365 requires a manual copy/paste into the wrap-up notes field[6].) While this works, it relies on agent diligence and is prone to error if the agent has the wrong record open. You should train agents to double-check the CRM tab before pasting the summary.

·       Automated method: A more robust approach is to use Genesys Cloud's APIs and Data Actions to transfer the summary directly. Genesys provides a Conversation Summaries API which allows you to retrieve the AI-generated summary programmatically[1]. Your integration can call GET /api/v2/conversations/{conversationId}/summaries (with appropriate authorization) once the call is complete to obtain the summary text and any AI-suggested fields (like reason or resolution). Then, using a Genesys Data Action or a custom service, push that summary into Dynamics. For example, you could update the Phone Call activity's description or add a note to the contact's timeline with the summary text. This automation eliminates copy/paste mistakes. Important: Do this only if conversationId is reliably tied to a Dynamics record. You might use a custom conversation attribute or the activity's CRM ID to correlate – for instance, InteractionSync can store Genesys Conversation ID on the Dynamics activity record[7][8]. By using such an identifier, your code can ensure it's updating the correct Dynamics record with the summary.

• In either case, make sure the Dynamics record is still active/valid at push time. If the agent had closed the CRM tab or if the integration did not find any contact, your push logic should detect that and refrain from sending. It's better to have a summary stay in Genesys (where it expires in 10 days) than to accidentally attach it to the wrong customer in D365.
• 5. Resetting Between Sessions: Each interaction (call/chat/etc.) should be treated as a separate summarization session tied to its own CRM context. Once an interaction is fully completed and the summary has (or hasn't) been pushed, you should reset any tracking variables or context flags in your integration layer. The next call an agent handles will likely pertain to a different account, so your logic should start fresh (waiting for a new screen-pop and context establishment). Genesys Cloud's Agent Co-Pilot will naturally separate summaries by conversation ID, so there's no data overlap on Genesys' side. Your job is to mirror that separation in the CRM integration. For example, if you were storing the current Dynamics record ID in a variable during the call, clear it out at call end. This prevents any chance that a new call could accidentally reuse a previous call's context. Also ensure the Genesys UI is reset – typically, the integration will open a new Dynamics activity for the next call, but if an agent manually stayed on an old record, be cautious. It is a best practice to navigate away from the last contact's screen after finishing ACW, or let the integration auto-pop the next one, so that the visible CRM context always matches the active interaction. The Genesys InteractionSync release notes even highlight multi-session management considerations (for example, a known issue was that if an agent opened a record via search rather than the screen-pop, a session ID wasn't generated[9], which could complicate context tracking). Being aware of such limitations, make sure to test and enforce context continuity between Genesys and D365 at the start and end of sessions.

By following the above practices, you effectively create a mechanism where Co-Pilot's summarization is contextually aware of the Dynamics 365 member session. The summary generation might be an automated AI feature, but you are wrapping it in rules that tie it to Dynamics' state: it "starts" when a customer is identified, it "stops" if the customer context is lost, it only "pushes" upon a valid conclusion with the correct customer, and it "resets" when moving to a new session.

Avoiding Cross-Account Contamination

A primary risk in any CRM-integrated summarization is that a summary from one customer interaction ends up attached to a different customer's record. Here are some best practices to prevent this "cross-account contamination":

·       Enforce One-Conversation/One-Record Linking: Ensure that each Genesys conversation ID is linked to at most one Dynamics record. If your agent tries to handle multiple accounts in one call (e.g. the caller asks about two different people's info – a rare but possible scenario), do not attempt to use one summary for both. Instead, the agent should split the call or notes accordingly. The integration should log the call under one primary contact or case in Dynamics. By keeping this one-to-one mapping, you eliminate ambiguity about where the summary should go.

·       Don't Share Summary Content Across Accounts: Never copy a summary from one member's activity into another's. If information from a call needs to be noted on two accounts (for instance, a conference call involving two clients), it's better to have the agent write separate notes for the second account manually. The Co-Pilot summary is tailored to the single interaction and should remain attached only to the records that were part of that interaction.

·       Use Unique Identifiers for Verification: As mentioned, leverage identifiers like the Genesys conversation ID or the Dynamics activity ID to track the linkage. Many organizations add a custom field in D365 for "Genesys Conversation ID" and populate it for each call activity[7]. This allows you to later audit where a summary was attached. If you ever see the same conversation ID on two different contact records, that's a red flag.

·       Train Agents on the Integration Workflow: Sometimes contamination happens due to human error – e.g. an agent might forget to switch the CRM record when a caller reveals new information ("Actually, I'm calling about my spouse's account, not mine"). Make sure agents know to update the CRM context ASAP in such cases (perhaps using the "Associations" feature to relink the call if needed). If they do that, your integration logic (start/stop/reset as discussed) should handle the rest – but the agent's awareness is the first line of defense.

·       Handle Multi-Tab Concurrency Carefully: If your agents can have multiple customer sessions open concurrently (for example, handling two chats at once with two different members), verify that the Genesys integration truly sandboxes each session. Co-Pilot should be running separately for each conversation. The risk here is lower because Genesys Cloud will generate two distinct summaries for two distinct interactions, but ensure your UI makes it clear which summary belongs to which session. Dynamics 365's multi-session interface usually keeps activities separated by tabs, and each Genesys interaction is associated with the correct tab when using the official integration. Still, it's wise to test this: have an agent handle two interactions and confirm that each Dynamics activity gets the correct notes and summary.

·       Monitor and Log Summary Pushes: Implement logging around the summary push operation. For example, if using a custom Data Action to send the summary to D365, log the conversation ID, target CRM entity, and timestamp. This way, if anything does go awry, you can trace it. Regularly review a few records to ensure summaries are appearing where they should.

·       Beware of "Stale" CRM Context: A common edge-case: the agent ends a call but leaves the Dynamics tab open on that contact, then later takes a new call and forgets that the old tab is still open. If your integration doesn't automatically pop a new tab (say the new call comes in unknown and doesn't pop), the agent might inadvertently paste a summary into the wrong contact's notes. To mitigate this, configure the integration to either always open a new session for each interaction (preferred), or have agents close out old sessions. Some integrations will auto-focus the relevant tab or update it; ensure that behavior is working. Using the session reset best practice from earlier (clearing context between calls) will help avoid this scenario.

In short, maintaining a strong binding between the conversation and the CRM record throughout the call prevents leakage of data across accounts. Each context change is an opportunity to either reinforce the correct link or to halt summarization until the link is corrected.

Verification and Testing

Implementing these controls is only half the battle – you'll want to rigorously test the summarization lifecycle to be confident it behaves as expected. Here are recommended techniques for verification:

·       Simulate Normal Calls: Place test calls where the caller matches exactly one Dynamics contact (or member account). Ensure the integration screen-pops that contact, the call logs to that contact's record, and when the call ends, the Co-Pilot summary appears only on that contact's timeline or activity. Verify that the summary content in D365 matches what Genesys Co-Pilot displayed. This tests the happy path end-to-end.

·       Test No-Context Scenario: Simulate a call from an unknown number that isn't in D365. The integration likely will not pop a contact (it might open a blank search or "new contact" form). Do not select or create any contact – let the call conclude without an associated record. The expectation: Co-Pilot may still generate a summary in the Genesys UI for the agent's reference, but no summary or call activity should appear in Dynamics. Check that no activity was inadvertently created, or if one was (some systems log the call to a generic record), confirm its notes are empty. Essentially, confirm that your "no context, no push" rule is honored.

·       Test Context Gained Mid-Call: Start a call with no initial CRM match, then during the call have the agent manually find and open the correct member record (perhaps the caller provides an email or account number that allows a manual search). Ensure that once the record is open, the rest of the call is logged under that record. When the call ends, the summary should be pushed to that newly selected record's activity. Check that the summary did attach to it, and nowhere else. This verifies that your late-binding of context still triggers the summary push correctly.

·       Test Context Switch Mid-Call: More complex: use a scenario where the wrong contact pops first. For example, two contacts with the same name and your integration pops the first one. Have the agent realize the mistake and switch to the second contact's record while on the call. After call completion, verify that the summary went to the second (correct) contact's record and that the first contact's record (which was initially opened) does not have any summary or has the activity reassigned. This is a crucial test for the "switch and reset" logic.

·       Concurrent Interactions: If applicable, have an agent handle two interactions concurrently (if your business allows, e.g. a voice call and a chat, or two chats). Confirm that two separate summaries are generated and each is pushed to the appropriate Dynamics record. The agent's interface should clearly separate the two (Dynamics will have two activities in two sessions). This test ensures no overlap in multi-tasking scenarios.

·       Long Calls and Edge Cases: Test a long call (over 30-40 minutes) to ensure summarization still functions (Genesys summarization might not produce output if conversation exceeds certain lengths[10]). Also test calls that transfer between agents: if your workflow involves transfers, ensure that when Agent A transfers to Agent B, the summary of Agent A's portion goes to the correct record and Agent B's summary goes to the correct record. (Out of the box, each agent gets their own summary for their portion[11][12]. In a CRM context, both parts should ideally log to the same customer's history – make sure your integration doesn't open a new contact for the second agent erroneously.)

·       Review Audit Trails: After testing, review the Dynamics records and Genesys conversation details. Check that each Dynamics activity has the right Genesys conversation ID (if you map it) and that it matches the conversation where the summary came from. Utilize Genesys's analytics or quality tools to cross-verify content if needed. Also consider enabling debug logging in InteractionSync (Genesys integration) during testing; it can show events like screen-pop, association changes, etc., which help confirm your "start/stop" hooks fired correctly.

By performing the above tests, you can be confident that Agent Co-Pilot summaries are being handled in a controlled, context-sensitive manner. Any discrepancies found should be addressed by refining the integration logic or user procedure before going live.

Conclusion

In a Genesys Cloud + Microsoft Dynamics 365 environment, tying AI summaries to the correct member account is essential for data accuracy, security, and usefulness. The Genesys Agent Co-Pilot feature is powerful, but without the proper context binding, its summaries could end up in the wrong place or at the wrong time. By enforcing that a valid D365 member session is in place for every summary, and by using lifecycle hooks to start, stop, push, or reset summarization based on CRM context, you create a tight coupling between the conversation and the CRM record. This not only prevents cross-account contamination of notes, but also ensures agents and supervisors can trust the summaries they see in Dynamics.

From a practical standpoint, implement the solution using the tools at your disposal: InteractionSync's screen-pop and activity mapping, Genesys conversation attributes and Summaries API, and Dynamics CIF events or custom scripting. Always fail safe – if something isn't right (no context, or context changed), err on the side of not pushing the summary automatically. It's better to have an agent manually intervene in an edge case than to have a summary attached to the wrong account. Finally, continuously monitor and refine the process. As Genesys and Microsoft update their integrations (for example, adding native support for summary injection in future releases), adapt your strategy to take advantage of those while keeping the fundamental requirement in mind: each summary goes to the one and only correct member record.

By following these best practices, Genesys Cloud administrators and developers can confidently deploy Agent Co-Pilot summarization in tandem with Dynamics 365, knowing that the right information will reach the right customer record every time. Your CRM will remain clean and accurate, and your agents will gain efficiency from AI summaries without introducing risk.

Tightly Binding Agent Co-Pilot Summaries to the Correct D365 Member Account

Introduction

Genesys Cloud's Agent Co-Pilot can automatically generate a summary of each customer interaction, which is extremely useful for after-call work. However, when integrating with Microsoft Dynamics 365 (D365), it's critical to ensure these AI-generated summaries are only pushed to the correct member's account record. If a summary is attached to the wrong account, it can lead to serious data integrity and privacy issues (often called cross-account contamination). The goal is to tightly bind the Co-Pilot summarization lifecycle – from start through push – to the active D365 customer context. In practice, this means the Co-Pilot summary process must be context-aware and only operate when an agent has a confirmed D365 member record open for the interaction. Genesys Cloud does support querying and exporting conversation summaries via API for CRM integration[1], but it's up to administrators and developers to implement the proper safeguards so summaries go to the right place. Below we outline the functional requirements and best practices for achieving this binding.

Key Functional Requirements

To guarantee that Co-Pilot summaries are linked to the correct Dynamics account, the following requirements must be met:

·       Context before Summarization: Summarization must not begin until a Dynamics 365 member account record is actively open/identified. In other words, Co-Pilot's auto-summary should only activate after the agent is viewing a confirmed customer record in D365. If an interaction isn't yet tied to a CRM contact/lead/account, the summarization feature should remain idle (or in a paused state).

·       No Context = No Summaries: If no D365 member record is open, Co-Pilot should not generate or display a summary. The system should effectively prevent or delay any auto-summarization when the CRM context is missing. This ensures you don't produce a summary that might accidentally be saved to the wrong place or require manual handling.

·       Validated Member for Push: When the call ends, push the summary to D365 only if a valid, active member record has been confirmed for that interaction. The integration must double-check that the conversation is associated with a specific Dynamics contact/account before transferring the summary text. If the CRM context was never set (or was lost), the summary should not be auto-sent into D365.

·       Reset on Session Change: If the agent closes the current member's session or switches to a different account record mid-interaction, the summarization process should reset. Any ongoing or pending summarization tied to the previous context should be cleared or halted to avoid mixing content between accounts. Essentially, Co-Pilot's summary lifecycle should be tightly scoped to one CRM session – when the agent moves to another customer or a new session, it should treat it as a fresh start.

·       Explicit Lifecycle Controls: Provide clear controls or hooks for "start, stop, push, reset" that are triggered by D365 context events. In practice, this means your integration or custom code should listen for events like record opened, record closed, record changed, and invoke the appropriate summarization control:

·       Start when a D365 member context is established (e.g. agent has an active contact open).

·       Stop/Pause if the context is removed or unknown (e.g. agent navigates away or no contact selected).

·       Push when ready to send the final summary to CRM (e.g. on call completion, if context is valid).

·       Reset when the session ends or the agent switches context (clearing any state so the next interaction starts cleanly).

These requirements enforce that an Agent Co-Pilot summary is always explicitly linked to a single, correct Dynamics 365 member record throughout its creation and delivery.

Implementing a Context-Bound Summarization Lifecycle

Meeting the above requirements involves configuring the Genesys–D365 integration and possibly adding custom logic. Below are best practices and implementation guidelines to tightly bind the summarization lifecycle to the CRM context:

• 1. Establish CRM Context Before Summarization: Leverage Genesys Cloud's integration (InteractionSync for D365) to identify and lock in the customer context at the start of the call. InteractionSync will typically do an automated screen-pop in Dynamics, searching for the incoming caller's record and opening it for the agent[2]. It also automatically creates a Dynamics activity (e.g. Phone Call record) for the interaction and associates it to the found contact/lead/account[2]. This means as soon as the call begins (and the caller is identified), there is a specific CRM record tied to the interaction. Ensure this screen-pop and activity creation is working reliably for your queues (configure the integration's lookup logic so that it finds the correct member by phone number or other identifiers). If the integration cannot find a match and the agent must search manually, make it a standard operating procedure that the agent selects or creates the correct member record before proceeding further. In summary: do not let the call progress to wrap-up or summary generation without an attached CRM context. This is the foundation – the Co-Pilot summary feature needs that "anchor" to a Dynamics record.
• 2. Gating Auto-Summarization on Context: Out-of-the-box, Agent Co-Pilot will generate a summary when an interaction is completed (disconnected) as long as the feature is enabled for that interaction type[3][4]. You can't truly "stop" Co-Pilot from attempting to summarize a conversation it handled – but you can gate whether that summary gets used or pushed to CRM. One strategy is to configure Co-Pilot or your business rules such that summarization is expected only in certain scenarios (for example, enable Co-Pilot on queues or interactions that are likely to have an identified customer). If an interaction ends and no Dynamics record was ever opened (meaning the call remained anonymous), simply do not transfer the summary anywhere. It will exist in Genesys for a brief period (by design, Co-Pilot summaries are stored for 10 days internally[5]), but your integration should treat it as a no-op in terms of CRM. In effect, Co-Pilot is "paused" waiting for a valid customer context. As soon as the agent does identify/open a member record (even if mid-call), that event can serve as the green light to resume or consider summarization active. If your integration is capable, you might even programmatically trigger the summary generation at that moment (e.g. by calling the summarization API at call end, once context is confirmed). The key is that no summary leaves Genesys Cloud unless a member context is set.
• 3. Hooking into Context Changes (Start/Stop): It's important to tie into the events of your CRM UI so you know when an agent has opened or closed a member's record. In Dynamics 365 (especially with the multi-session interface for Customer Service), each session/tab corresponds to a customer issue or account context. The Genesys integration can be extended via the Dynamics Channel Integration Framework (CIF) or client-side scripts to detect when a new session starts or ends. For example:

·       When a screen pop occurs and opens a contact, have that trigger a "Start Summarization" event in your logic. This could be as simple as setting a flag in the Genesys conversation's participant data that "CRM Context = [ContactID] established", or enabling a timer/collection of transcript for summary. From this point, Co-Pilot can continue transcribing and later summarizing, confident there's an associated account.

·       If the agent closes the contact tab or Dynamics session before the call is over (intentionally or accidentally), catch that event to "Pause Summarization." In practice, you might set a flag like "context lost" which tells your post-call routine not to push any summary. You could even alert the agent or require them to re-open the member record. This prevents a scenario where a summary is generated with nowhere in CRM to go.

·       If the agent switches to a different account record during the call (for instance, they realized the initial screen-pop was the wrong John Smith and they pulled up a different John Smith's record), then you should treat that similar to closing one context and starting another. In other words, reset the summarization binding – mark the old context as inactive and the new one as the official context. Technically, the conversation's transcript is continuous, but by resetting and re-binding to the new record, you ensure the final summary will be linked to the correct customer. (If your integration created an activity on the first record, you may need to update it or create a new one on the correct record – the Dynamics "regarding" field of the Phone Call can be changed to the new contact if needed so that all notes and the summary ultimately relate to the right person.)

• Some Genesys–CRM integrations also support an "Associations" feature in the agent's call log, which allows manually re-linking an interaction to a different CRM entity if needed. If your agents use that, tie your summarization logic to the final association they set. Essentially, always refer to the current associated member record when deciding where to send the summary.
• 4. Pushing the Summary to D365 (Finalize on Call End): The actual handoff of the summary to Dynamics should occur at the end of the call, during the after-call work (ACW) phase or immediately after. This is when Genesys Co-Pilot presents the generated summary to the agent in the interface[3]. At this point, your integration or custom process should do a final check: "Do we have a valid Dynamics member ID for this conversation?" If yes, proceed to push; if not, skip it. Pushing the summary can be accomplished in a couple of ways:

·       Manual method: The agent can copy the Co-Pilot summary text from Genesys and paste it into the call notes or a custom field in the Genesys sidebar, which will sync to the Dynamics activity. (As of mid-2024, this was the primary method – Genesys confirmed that Co-Pilot summarization for D365 requires a manual copy/paste into the wrap-up notes field[6].) While this works, it relies on agent diligence and is prone to error if the agent has the wrong record open. You should train agents to double-check the CRM tab before pasting the summary.

·       Automated method: A more robust approach is to use Genesys Cloud's APIs and Data Actions to transfer the summary directly. Genesys provides a Conversation Summaries API which allows you to retrieve the AI-generated summary programmatically[1]. Your integration can call GET /api/v2/conversations/{conversationId}/summaries (with appropriate authorization) once the call is complete to obtain the summary text and any AI-suggested fields (like reason or resolution). Then, using a Genesys Data Action or a custom service, push that summary into Dynamics. For example, you could update the Phone Call activity's description or add a note to the contact's timeline with the summary text. This automation eliminates copy/paste mistakes. Important: Do this only if conversationId is reliably tied to a Dynamics record. You might use a custom conversation attribute or the activity's CRM ID to correlate – for instance, InteractionSync can store Genesys Conversation ID on the Dynamics activity record[7][8]. By using such an identifier, your code can ensure it's updating the correct Dynamics record with the summary.

• In either case, make sure the Dynamics record is still active/valid at push time. If the agent had closed the CRM tab or if the integration did not find any contact, your push logic should detect that and refrain from sending. It's better to have a summary stay in Genesys (where it expires in 10 days) than to accidentally attach it to the wrong customer in D365.
• 5. Resetting Between Sessions: Each interaction (call/chat/etc.) should be treated as a separate summarization session tied to its own CRM context. Once an interaction is fully completed and the summary has (or hasn't) been pushed, you should reset any tracking variables or context flags in your integration layer. The next call an agent handles will likely pertain to a different account, so your logic should start fresh (waiting for a new screen-pop and context establishment). Genesys Cloud's Agent Co-Pilot will naturally separate summaries by conversation ID, so there's no data overlap on Genesys' side. Your job is to mirror that separation in the CRM integration. For example, if you were storing the current Dynamics record ID in a variable during the call, clear it out at call end. This prevents any chance that a new call could accidentally reuse a previous call's context. Also ensure the Genesys UI is reset – typically, the integration will open a new Dynamics activity for the next call, but if an agent manually stayed on an old record, be cautious. It is a best practice to navigate away from the last contact's screen after finishing ACW, or let the integration auto-pop the next one, so that the visible CRM context always matches the active interaction. The Genesys InteractionSync release notes even highlight multi-session management considerations (for example, a known issue was that if an agent opened a record via search rather than the screen-pop, a session ID wasn't generated[9], which could complicate context tracking). Being aware of such limitations, make sure to test and enforce context continuity between Genesys and D365 at the start and end of sessions.

By following the above practices, you effectively create a mechanism where Co-Pilot's summarization is contextually aware of the Dynamics 365 member session. The summary generation might be an automated AI feature, but you are wrapping it in rules that tie it to Dynamics' state: it "starts" when a customer is identified, it "stops" if the customer context is lost, it only "pushes" upon a valid conclusion with the correct customer, and it "resets" when moving to a new session.

Avoiding Cross-Account Contamination

A primary risk in any CRM-integrated summarization is that a summary from one customer interaction ends up attached to a different customer's record. Here are some best practices to prevent this "cross-account contamination":

·       Enforce One-Conversation/One-Record Linking: Ensure that each Genesys conversation ID is linked to at most one Dynamics record. If your agent tries to handle multiple accounts in one call (e.g. the caller asks about two different people's info – a rare but possible scenario), do not attempt to use one summary for both. Instead, the agent should split the call or notes accordingly. The integration should log the call under one primary contact or case in Dynamics. By keeping this one-to-one mapping, you eliminate ambiguity about where the summary should go.

·       Don't Share Summary Content Across Accounts: Never copy a summary from one member's activity into another's. If information from a call needs to be noted on two accounts (for instance, a conference call involving two clients), it's better to have the agent write separate notes for the second account manually. The Co-Pilot summary is tailored to the single interaction and should remain attached only to the records that were part of that interaction.

·       Use Unique Identifiers for Verification: As mentioned, leverage identifiers like the Genesys conversation ID or the Dynamics activity ID to track the linkage. Many organizations add a custom field in D365 for "Genesys Conversation ID" and populate it for each call activity[7]. This allows you to later audit where a summary was attached. If you ever see the same conversation ID on two different contact records, that's a red flag.

·       Train Agents on the Integration Workflow: Sometimes contamination happens due to human error – e.g. an agent might forget to switch the CRM record when a caller reveals new information ("Actually, I'm calling about my spouse's account, not mine"). Make sure agents know to update the CRM context ASAP in such cases (perhaps using the "Associations" feature to relink the call if needed). If they do that, your integration logic (start/stop/reset as discussed) should handle the rest – but the agent's awareness is the first line of defense.

·       Handle Multi-Tab Concurrency Carefully: If your agents can have multiple customer sessions open concurrently (for example, handling two chats at once with two different members), verify that the Genesys integration truly sandboxes each session. Co-Pilot should be running separately for each conversation. The risk here is lower because Genesys Cloud will generate two distinct summaries for two distinct interactions, but ensure your UI makes it clear which summary belongs to which session. Dynamics 365's multi-session interface usually keeps activities separated by tabs, and each Genesys interaction is associated with the correct tab when using the official integration. Still, it's wise to test this: have an agent handle two interactions and confirm that each Dynamics activity gets the correct notes and summary.

·       Monitor and Log Summary Pushes: Implement logging around the summary push operation. For example, if using a custom Data Action to send the summary to D365, log the conversation ID, target CRM entity, and timestamp. This way, if anything does go awry, you can trace it. Regularly review a few records to ensure summaries are appearing where they should.

·       Beware of "Stale" CRM Context: A common edge-case: the agent ends a call but leaves the Dynamics tab open on that contact, then later takes a new call and forgets that the old tab is still open. If your integration doesn't automatically pop a new tab (say the new call comes in unknown and doesn't pop), the agent might inadvertently paste a summary into the wrong contact's notes. To mitigate this, configure the integration to either always open a new session for each interaction (preferred), or have agents close out old sessions. Some integrations will auto-focus the relevant tab or update it; ensure that behavior is working. Using the session reset best practice from earlier (clearing context between calls) will help avoid this scenario.

In short, maintaining a strong binding between the conversation and the CRM record throughout the call prevents leakage of data across accounts. Each context change is an opportunity to either reinforce the correct link or to halt summarization until the link is corrected.

Verification and Testing

Implementing these controls is only half the battle – you'll want to rigorously test the summarization lifecycle to be confident it behaves as expected. Here are recommended techniques for verification:

·       Simulate Normal Calls: Place test calls where the caller matches exactly one Dynamics contact (or member account). Ensure the integration screen-pops that contact, the call logs to that contact's record, and when the call ends, the Co-Pilot summary appears only on that contact's timeline or activity. Verify that the summary content in D365 matches what Genesys Co-Pilot displayed. This tests the happy path end-to-end.

·       Test No-Context Scenario: Simulate a call from an unknown number that isn't in D365. The integration likely will not pop a contact (it might open a blank search or "new contact" form). Do not select or create any contact – let the call conclude without an associated record. The expectation: Co-Pilot may still generate a summary in the Genesys UI for the agent's reference, but no summary or call activity should appear in Dynamics. Check that no activity was inadvertently created, or if one was (some systems log the call to a generic record), confirm its notes are empty. Essentially, confirm that your "no context, no push" rule is honored.

·       Test Context Gained Mid-Call: Start a call with no initial CRM match, then during the call have the agent manually find and open the correct member record (perhaps the caller provides an email or account number that allows a manual search). Ensure that once the record is open, the rest of the call is logged under that record. When the call ends, the summary should be pushed to that newly selected record's activity. Check that the summary did attach to it, and nowhere else. This verifies that your late-binding of context still triggers the summary push correctly.

·       Test Context Switch Mid-Call: More complex: use a scenario where the wrong contact pops first. For example, two contacts with the same name and your integration pops the first one. Have the agent realize the mistake and switch to the second contact's record while on the call. After call completion, verify that the summary went to the second (correct) contact's record and that the first contact's record (which was initially opened) does not have any summary or has the activity reassigned. This is a crucial test for the "switch and reset" logic.

·       Concurrent Interactions: If applicable, have an agent handle two interactions concurrently (if your business allows, e.g. a voice call and a chat, or two chats). Confirm that two separate summaries are generated and each is pushed to the appropriate Dynamics record. The agent's interface should clearly separate the two (Dynamics will have two activities in two sessions). This test ensures no overlap in multi-tasking scenarios.

·       Long Calls and Edge Cases: Test a long call (over 30-40 minutes) to ensure summarization still functions (Genesys summarization might not produce output if conversation exceeds certain lengths[10]). Also test calls that transfer between agents: if your workflow involves transfers, ensure that when Agent A transfers to Agent B, the summary of Agent A's portion goes to the correct record and Agent B's summary goes to the correct record. (Out of the box, each agent gets their own summary for their portion[11][12]. In a CRM context, both parts should ideally log to the same customer's history – make sure your integration doesn't open a new contact for the second agent erroneously.)

·       Review Audit Trails: After testing, review the Dynamics records and Genesys conversation details. Check that each Dynamics activity has the right Genesys conversation ID (if you map it) and that it matches the conversation where the summary came from. Utilize Genesys's analytics or quality tools to cross-verify content if needed. Also consider enabling debug logging in InteractionSync (Genesys integration) during testing; it can show events like screen-pop, association changes, etc., which help confirm your "start/stop" hooks fired correctly.

By performing the above tests, you can be confident that Agent Co-Pilot summaries are being handled in a controlled, context-sensitive manner. Any discrepancies found should be addressed by refining the integration logic or user procedure before going live.

Conclusion

In a Genesys Cloud + Microsoft Dynamics 365 environment, tying AI summaries to the correct member account is essential for data accuracy, security, and usefulness. The Genesys Agent Co-Pilot feature is powerful, but without the proper context binding, its summaries could end up in the wrong place or at the wrong time. By enforcing that a valid D365 member session is in place for every summary, and by using lifecycle hooks to start, stop, push, or reset summarization based on CRM context, you create a tight coupling between the conversation and the CRM record. This not only prevents cross-account contamination of notes, but also ensures agents and supervisors can trust the summaries they see in Dynamics.

From a practical standpoint, implement the solution using the tools at your disposal: InteractionSync's screen-pop and activity mapping, Genesys conversation attributes and Summaries API, and Dynamics CIF events or custom scripting. Always fail safe – if something isn't right (no context, or context changed), err on the side of not pushing the summary automatically. It's better to have an agent manually intervene in an edge case than to have a summary attached to the wrong account. Finally, continuously monitor and refine the process. As Genesys and Microsoft update their integrations (for example, adding native support for summary injection in future releases), adapt your strategy to take advantage of those while keeping the fundamental requirement in mind: each summary goes to the one and only correct member record.

By following these best practices, Genesys Cloud administrators and developers can confidently deploy Agent Co-Pilot summarization in tandem with Dynamics 365, knowing that the right information will reach the right customer record every time. Your CRM will remain clean and accurate, and your agents will gain efficiency from AI summaries without introducing risk.