Introduction
Google CCAI Interview Questions and Answers – If you landed here first, start with Part 1, which covers CCAI Platform fundamentals, instance sizing, queues/routing, omnichannel, and conversational AI. This is Part 2 of the 4-part series, and it goes deep on the topics that separate a generalist candidate from a true CCAI Platform solution architect: CRM integration architecture, the Manager API vs. Apps API vs. Chat Platform API, SDK authentication patterns, and enterprise security controls like VPC Service Controls and audit logging.
Every answer below is written in plain language first, then anchored to specific, verifiable details from Google’s official CCAI Platform documentation — so you can use this not just to memorize an answer, but to actually explain why it’s true in a live interview or design review.
Section G: CRM Integration Architecture
51. Why does CCAI Platform emphasize CRM integration so heavily in its architecture?
CCAI Platform is explicitly designed to work alongside CRMs rather than replace them — Google positions it as providing “a single source of truth for customer journeys” while the CRM remains the system of record for customer data. Architecturally, this means CCAI Platform focuses on real-time interaction handling, routing, and AI, while pushing session data, transcripts, and disposition outcomes into whichever CRM the business already runs — Salesforce, HubSpot, Zendesk, ServiceNow, Microsoft Dynamics, Oracle, Kustomer, Freshdesk, or a custom CRM.
52. Which Salesforce editions are supported for CCAI Platform integration?
Salesforce Professional, Enterprise, Performance, Unlimited, and Developer editions are all supported. Notably, the Essentials edition is explicitly not supported — a detail architects should confirm during discovery, since some smaller customers run Essentials and would need to upgrade their Salesforce license before integration is possible.
53. What are the high-level steps to install the CCAI Platform Salesforce package?
The installation flow is: (1) locate your Salesforce Org ID and Org Name and add them to the CCAI Platform portal; (2) install the managed package into Salesforce; (3) create a Salesforce Connected App and retrieve its consumer key/secret; (4) enter that consumer key/secret into the CCAI Platform portal’s Developer Settings; (5) manage the configuration inside Salesforce (custom settings, permission sets); and (6) configure the Salesforce Call Center for the agent adapter. Package version matters here — Lead object support, for instance, requires package version 1.18 or higher (1.20+ recommended).
54. What is the CCAI Platform “session object” in Salesforce, and why would you enable it?
By default, CCAI Platform session data (call/chat details) is stored on the standard Salesforce Activity object. When the dedicated CCAI Platform Session Object is enabled instead, all session data is stored in its own object type, attached directly to the Case, and a single Case can have multiple sessions attached to it — which matters for scenarios like a customer calling back multiple times about the same open issue. This is a common architecture decision point: Activity object is simpler for smaller deployments, while the dedicated Session Object gives cleaner reporting for high-volume, multi-touch case scenarios.
55. What is domain-based access control, and why is it a Salesforce integration prerequisite?
Domain-based access control lets administrators explicitly define which domains are permitted to load and display the CCAI Platform agent adapter (for security, this prevents the adapter from being embedded on unauthorized pages). It’s called out as a prerequisite implementation step for Salesforce specifically, and Google’s documentation warns that adding new domains can cause a temporary disruption to the adapter — so it should be done during low call-volume periods or a scheduled maintenance window, not mid-shift.
56. What is CRM record creation in CCAI Platform, and what does “skip CRM account and record creation” mean?
CRM record creation is the automated process where CCAI Platform creates or updates Case/Ticket, Contact, and Account records in the connected CRM whenever a new session starts. “Skip CRM account and record creation” is a configuration option for scenarios where you don’t want that automatic behavior — for example, if a separate system already owns record creation, or you want agents to manually decide whether a session warrants a new CRM record, avoiding duplicate or junk records from abandoned or misdialed sessions.
57. What is CRM custom field mapping used for?
Custom field mapping lets administrators map CCAI Platform session data (queue name, wait time, disposition code, virtual agent transcript, etc.) to custom fields you’ve already built in your CRM, rather than being limited to a fixed set of standard fields. This is essential for organizations with mature CRM data models who need session data to slot into existing reporting structures instead of creating parallel, disconnected data sets.
58. What is the “CRM default administrator” setting?
This setting defines a fallback administrative user/service account in the CRM that CCAI Platform uses for record creation and API calls when a specific agent’s own CRM credentials aren’t applicable — commonly used to ensure system-level integrations (like automated record creation from an IVR-only interaction) still succeed even if no live agent was involved in the session.
59. Why does CCAI Platform document CRM API rate limits explicitly?
Because CRMs like Salesforce and HubSpot enforce their own API call limits, and a busy contact center generating high call/chat volume can hit those ceilings quickly if integration isn’t designed carefully. Google’s documentation on CRM rate limits exists specifically so architects can plan batching, caching, or throttling strategies (for example, avoiding a 1:1 API call per session in extremely high-volume queues) to prevent the CRM integration from silently failing during peak traffic.
60. When would you recommend the Custom CRM framework over a native integration?
The Custom CRM guide (with its EspoCRM reference implementation) is the right recommendation when a customer runs a CRM not on Google’s native-integration list (Salesforce, HubSpot, Zendesk, ServiceNow, Dynamics, Oracle, Kustomer, Freshdesk), or when they’ve built a proprietary internal case-management system. It gives architects a documented, supported pattern for wiring session metadata and record creation into any REST-capable backend rather than building an unsupported one-off integration from scratch.
Section H: Manager API & Apps API Deep Dive
61. What is the fundamental architectural difference between the Manager API and the Apps API?
The Manager API extends features related to system settings, configuration, events, and activities — it’s the administrative/back-office API, grouped into Agent, Agent Activity, Campaigns, Calls, Chats, Emails, Menu (queues), Team, and User Status endpoint categories. The Apps API extends the channel-facing features of the platform — calls, chats, and SMS — grouped into Agent Status, Bulk User Management, Calls, Campaigns, Chats, Co-browse (Screen Share), Company Do Not Call list, Contact Data, End Users, Force Agent Logout, SMS, and Wait Times. In short: Manager API = “manage the system,” Apps API = “power the customer/agent experience.”
62. How does authentication work for the Manager API and Apps API?
Both APIs use HTTP Basic Authentication. You generate credentials in the CCAI Platform portal under Settings > Developer Settings > API Credentials, where your instance subdomain (for example, customer in https://customer.uc1.ccaiplatform.com) becomes the {username}, and the generated API token becomes the {password}. Critically, the API key/token cannot be retrieved later once generated — only regenerated — so it must be captured and stored securely (e.g., in a secrets manager) the moment it’s created.
63. How does pagination work in the Manager API, and what should you watch for?
By default, the Manager API returns 100 records per response, but this is configurable. There is no explicit “has more pages” flag in the payload itself — instead, a response header indicates the total number of records available; if that total exceeds 100 (or your configured page size), you know additional pages exist. You paginate using the page parameter and control page size with the per parameter.
64. What is API “tailing,” and why does it matter for integrations?
Tailing is the recommended pattern for continuously pulling newly updated records from the Manager API — rather than re-querying the entire dataset on every poll, you filter using a timestamp parameter (e.g., updated_at[from]=<timestamp>) combined with sort direction, so your integration only retrieves records that changed since the last successful poll. This is the standard approach for building near-real-time sync jobs into a data warehouse or BI tool without hammering the API with full-dataset requests.
65. What does the Agent endpoints group in the Manager API expose?
The Agent endpoints return individual agent resource objects — for example, GET /manager/api/v1/agents/current_status returns each agent’s ID, current status (e.g., “Available”), status ID, the timestamp of the last status change, and hold-call state/duration. Google’s documentation specifically flags that some fields in the agent model may contain personally identifiable information (PII), which is an important callout for data-governance and privacy-review conversations during implementation.
66. What does the User Status endpoint represent, and how is it different from Agent Status?
User Status endpoints describe the catalog of possible statuses an agent can be placed into (built-in ones like “Available”/”Break,” plus any custom statuses an admin configures) — each represented by an ID, workforce-management ID, name, and color. Agent Status, by contrast, reflects which status a specific agent is currently in. Think of User Status as the dictionary of possible states, and Agent Status as “which word from that dictionary applies to this agent right now.”
67. Are Manager API and Apps API responses guaranteed to be stable over time?
Google documents that all API updates are backward compatible, but explicitly reserves the right to introduce new JSON keys into existing API responses at any time. The documented best practice is to build your integration to defensively ignore unrecognized keys, rather than using strict schema validation that would break the moment Google adds a new field — a detail that’s easy to miss and a great “gotcha” interview question.
68. What does the Emergency Shutdown endpoint in the Apps API let you do?
It’s a programmatic version of the admin-console emergency queue shutdown capability — allowing an external system (like an incident-management or monitoring tool) to automatically trigger a shutdown of interactions to a queue based on a defined trigger condition, rather than requiring a human admin to manually intervene through the portal during an outage or incident.
69. What is the Bulk User Management API used for?
It provides programmatic create/update/deactivate operations for large batches of CCAI Platform users, mirroring the “Bulk User Management” and “Bulk User Sync Tool” capabilities available in the portal UI — this is the endpoint category architects reach for when a customer’s HR/identity system needs to keep hundreds or thousands of agent accounts in sync automatically, rather than relying on manual CSV uploads.
70. What is the “Contact data” endpoint category, and how does it relate to campaigns?
Contact data endpoints manage the records used to drive outbound campaigns — the phone numbers/contact lists that predictive, progressive, and preview dialers pull from. This ties directly into the Company Do Not Call (DNC) list endpoints, since any outbound campaign integration must cross-reference contact data against DNC entries before dialing, for both compliance and customer-experience reasons.
Also check – Amazon connect interview questions and answers
Section I: Chat Platform API, SMS API & Webhooks
71. What is the Chat Platform API, and who is it designed for?
The Chat Platform API is designed for organizations that want to build or embed their own custom chat interface (rather than using CCAI Platform’s native Web/Mobile SDK chat widget) while still routing those conversations through CCAI Platform’s queueing, virtual agent, and agent-adapter infrastructure on the backend. It communicates in two directions: your application makes authenticated REST calls to CCAI Platform (e.g., POST /chats/:id/message to send a message), and CCAI Platform sends webhook events back to your server (e.g., message_received) to notify you of activity in real time.
72. How are Chat Platform API webhooks secured?
Every webhook request includes two headers: X-Signature and X-Signature-Timestamp. The X-Signature header contains a primary and secondary signature, each a base64-encoded SHA-256 digest computed from the corresponding webhook secret combined with the timestamp. Integrators are expected to verify every webhook signature before processing the event, and to store processed event IDs so that retried webhook deliveries don’t cause duplicate processing.
73. What best practices does Google document for consuming Chat Platform API webhooks reliably?
Key practices include: verify the signature on every event; persist a deterministic event key or ID so retries are idempotent; return a 2xx response promptly after accepting the event (processing heavier downstream logic asynchronously rather than inline); and remember that the initial API response and the corresponding webhook event can arrive in either order — so your system should treat both as updates to the same underlying chat record, keyed by chat ID, rather than assuming a strict sequence.
74. How does photo/video attachment sharing work through the Chat Platform API?
Rather than uploading binary content directly in the message payload, the API flow is: your application requests a pre-signed upload URL for a configured Cloud Storage bucket from CCAI Platform, uploads the photo/video directly to that storage location, and then sends the resulting storage URL as the message payload. This keeps large binary transfers off the core messaging API and leverages Cloud Storage’s own upload performance and security model.
75. What is the API Direct Access Point (DAP) for chat?
API DAP for chat lets incoming chat sessions be automatically routed to a specific queue based on a response from an external API endpoint you configure, removing the need for end-users to manually pick from a queue-selection menu. This feature is off by default and must be explicitly enabled by Google Cloud Support for your instance — a detail worth knowing since it’s a common surprise during technical scoping (“why isn’t API DAP working out of the box?”).
76. What rate-limiting behavior should integrators expect from the Apps API?
CCAI Platform applies rate limits to Apps API traffic, and Google’s own integration guidance explicitly recommends building retries with exponential backoff into your integration and avoiding bursts of requests for a single tenant. This is a critical design consideration for any high-throughput integration (e.g., a virtual task assistant firing frequent status updates) to avoid being throttled during peak periods.
77. What is the SMS API, and how does it relate to Direct SMS numbers?
The SMS API lets external systems send and receive SMS messages through CCAI Platform programmatically — layering on top of the platform’s native SMS capabilities like wait-time SMS, app-download SMS, and direct SMS numbers. It’s the integration point of choice when a business wants SMS-based support triggered from outside systems (e.g., an e-commerce order-status page offering “text us” support) rather than only from CCAI Platform’s own IVR/queue configuration.
Also check – Ring Central interview questions and answers
Section J: SDKs — Web, Mobile & Authentication
78. What’s the difference between Web SDK v2 and Web SDK v3?
Web SDK v3 is the current, actively enhanced generation of the browser SDK, with a documented upgrade path from v2 and its own theme customization, message/translation customization, and API reference. Web SDK v2 remains supported for existing implementations that haven’t migrated yet, but new implementations should default to v3 unless there’s a specific legacy compatibility reason not to.
79. What is the Headless Web SDK, and when would you choose it over the standard Web SDK?
The Headless Web SDK provides the same underlying calling/chat engine as the standard Web SDK but with no built-in UI — giving development teams full control to build a fully custom-branded interface using their own component library or design system, while CCAI Platform still handles session logic, queueing, and events under the hood. Choose it when brand/design requirements are strict enough that the standard SDK’s theming options aren’t sufficient.
80. How do you initialize the CCAI Platform Web SDK v3, at a high level?
You instantiate a new UJET(options) object (the SDK’s class name reflects CCAI Platform’s UJET heritage), passing a companyId, either a host or tenant value (tenant is simply your instance subdomain — CCAI Platform derives the host automatically from it), and an authenticate function that your frontend calls to retrieve a signed JWT from your own backend. You then call .config({...}) to apply further configuration before invoking the SDK’s calling/chat methods.
81. Why does CCAI Platform require backend-signed JWT authentication for its SDKs, instead of a simple API key in the client?
Because the Web, iOS, and Android SDKs run in untrusted client environments (browsers, mobile apps) where any embedded secret could be extracted and abused. Instead, the architecture requires your own backend server to hold a private company secret, use it to sign a JWT (embedding the end-user’s identifier, and optionally username/email/phone) via a library like the jwt gem, and return only that short-lived signed token to the client SDK — keeping the actual secret off any device a customer could inspect.
82. What is mid-session authentication, and why would you use it?
Mid-session authentication lets an end-user start a support session anonymously (for example, opening a chat before logging in) and then, once they authenticate later in the conversation, link that in-progress session to their verified identity using a dedicated call/chat API endpoint. This is valuable for reducing friction at the start of a support interaction while still getting the benefit of an authenticated, CRM-linked session once identity is confirmed — common in e-commerce and banking use cases where initial questions are general but later ones require verification.
83. What SDK options exist specifically for Android developers?
Beyond the native Android SDK, CCAI Platform documents dedicated guides for Flutter for Android and React Native for Android, letting cross-platform mobile teams integrate CCAI Platform’s calling and chat capabilities without writing separate native Kotlin/Java integration code for each framework they support.
84. What SDK options exist specifically for iOS developers?
Similarly, alongside the native iOS SDK, CCAI Platform documents Flutter for iOS and React Native for iOS guides — mirroring the Android side so a single cross-platform codebase (Flutter or React Native) can integrate consistently across both mobile platforms.
85. What is the Mobile SDK’s PSTN Fallback feature?
PSTN Fallback automatically switches a VoIP call to a traditional cellular (PSTN) call when the end-user’s data connection is too weak to sustain voice quality — critically, it does this while still transmitting the important custom data packet to the CRM record, so the agent doesn’t lose context just because the call type changed mid-session.
86. What are SmartActions in the Mobile SDK?
SmartActions let agents trigger in-app actions on the end-user’s device mid-session — such as instantly verifying identity via Touch ID/Face ID (iOS) or fingerprint/face/passcode (Android), or requesting the user submit photos, videos, screenshots, or text input — directly through the support session, without asking the customer to separately email evidence or switch communication channels.
87. What is End User Authentication in the context of the SDK guides, and how does it differ across iOS, Android, and Web?
“End User Authentication” is the umbrella pattern (documented as SDK End User Authentication) where each SDK — iOS, Android, and Web — calls your backend’s signing endpoint to retrieve a JWT before establishing a session. The mechanics differ slightly by platform (iOS/Android typically issue an HTTP POST to fetch the token directly, while Web SDK implements an authentication handler that makes an AJAX request and passes the token plus user info to the SDK’s initialization function), but the underlying security model — client never holds the signing secret — is identical across all three.
Also check – Genesys interview questions and answers
Section K: Security, Compliance & Governance
88. What happens when you place a CCAI Platform instance inside a VPC Service Controls perimeter?
The instance is prevented from exchanging data with Google Cloud services — such as Cloud Storage or Dialogflow CX — that sit outside that perimeter. You can further harden this by adding the CCAI Platform API itself to your list of restricted services, and then defining an access level so that only authorized administrators can still manage the instance through the Google Cloud console.
89. Does VPC Service Controls restrict CCAI Platform’s communication with third-party, non-Google services?
No — and this is a frequently misunderstood point in interviews. Including a CCAI Platform instance in a VPC-SC perimeter only governs data exchange with other Google Cloud services. It does not restrict the instance from exchanging data with third-party services (like a non-Google CRM or carrier). To lock down third-party/external data exchange, Google’s documented recommendation is to use Private Service Connect to configure private ingress and private egress instead.
90. What kind of activity does CCAI Platform’s audit logging cover, and what doesn’t it cover?
CCAI Platform’s Cloud Audit Logging (for the contactcenteraiplatform.googleapis.com API) captures infrastructure-level events — for example, when a CCAI Platform instance itself is created or deleted. It explicitly does not cover user-level actions inside the contact center application — such as agents, managers, or admins signing in or changing settings. To obtain logs for those user actions, you must contact Cloud Support directly and provide your project, region, a Cloud Storage bucket (with write access granted to Support), and the specific date/time window (within the last 30 days) you need logs for.
91. Why would an architect need to know that user-action audit logs require a Cloud Support request?
Because it directly affects incident-response planning and compliance commitments. If a customer’s compliance team expects self-service, real-time audit trails for every agent login and settings change, that expectation needs to be corrected early — the current documented process is a manual request to Cloud Support with a 30-day lookback window, not an always-on exportable log stream, which is an important limitation to flag during a security design review.
92. What are custom constraints in CCAI Platform’s IAM/organization policy model?
Custom constraints let organizations define their own fine-grained organization-policy rules on top of Google Cloud’s built-in constraints — for example, restricting which regions a CCAI Platform instance can be created in, or which components can be provisioned, beyond what Google’s default policy set covers. This gives large enterprises a way to enforce internal governance standards (data residency, approved regions, naming conventions) automatically rather than relying purely on manual review.
93. What is domain-based access control, and is it only relevant to Salesforce?
While it’s called out specifically as a Salesforce integration prerequisite, domain-based access control is actually a general CCAI Platform agent-adapter security feature — it restricts which web domains are permitted to embed and load the agent adapter, which is relevant to any CRM or custom application embedding the adapter, not just Salesforce. Architects should treat it as a standard hardening step for every embedded-adapter deployment.
94. What is IP allow-listing, and where is it used in CCAI Platform?
IP allow-listing is available at two levels: the agent adapter level (restricting which network IPs agent workstations can connect from) and the BYOC level (restricting which carrier/SIP IPs are trusted to originate telephony traffic into your instance). Both are essential controls for enterprises with strict network-perimeter security requirements, especially those supporting remote/work-from-home agents who must still connect only from approved, firewall-cleared networks.
<a id=”section-l”></a>
Section L: Reporting, Dashboards & Operational Best Practices
95. What’s the difference between Standard Reports and Advanced Reporting Dashboards in CCAI Platform?
Standard Reports are the built-in, dataset-driven reports covering agents/teams, interactions, queues, supervisory monitoring, virtual agents, voicemail, and campaigns — designed for straightforward operational reporting out of the box. Advanced Reporting Dashboards are a more powerful, configurable analytics layer (built on Looker) offering deeper dashboards — performance overview, real-time channel performance, queue and agent monitoring, CSAT, dispositions, and more — plus the ability to create custom Looks, build dashboards from those Looks, and organize them into folders. Advanced reporting must be explicitly enabled during instance creation (and is only available in supporting regions).
96. What is a “Look” in the context of CCAI Platform’s advanced reporting dashboards?
A Look is a saved, reusable query/visualization (a Looker concept) that can be linked or saved directly onto a dashboard, letting administrators build custom analytical views — beyond the pre-built dashboard tiles — and then standardize those views across multiple dashboards or teams without rebuilding the same query repeatedly.
97. What is the Data Dictionary, and why do architects rely on it heavily?
The Data Dictionary is the canonical reference for every field, metric, and terminology used across CCAI Platform’s session metadata, raw data export, and reporting layers. Architects lean on it constantly during integration design and BI work because it defines precisely what each metric means (e.g., how a specific wait-time or handle-time field is calculated), preventing costly misinterpretation when building custom reports or data pipelines.
98. What is Raw Data Export, and when would you use it instead of Standard Reports or the Reporting API?
Raw Data Export provides granular, session-level event data (with its own documented dictionary and JSON schema) intended for organizations that want to pipe complete, unaggregated interaction data into their own data warehouse or BI platform for custom analysis — rather than relying on Google’s pre-aggregated Standard Reports or dashboard tiles. It’s the right choice when a customer’s analytics team needs full control over how metrics are calculated and joined with other business data.
99. What is the difference between QM/SIPREC integration and Verint integration in CCAI Platform’s session data export?
QM and SIPREC integration is the general framework for streaming call/chat session events to third-party Quality Management (QM) systems using the SIPREC protocol standard for call recording capture. The Verint integration is a named, vendor-specific implementation of that same pattern, purpose-built for organizations standardized on Verint’s QM/WFM suite — illustrating how CCAI Platform supports both a generic, protocol-based export path and dedicated named-vendor integrations for the most common enterprise QM platforms.
100. What operational best practice should architects follow before recommending an Advanced Reporting Dashboard rollout?
Confirm the target region actually supports Advanced Reporting before instance creation — the checkbox to enable it is inactive for regions where it isn’t supported, and since region cannot be changed after instance creation, choosing the wrong region locks the customer out of advanced dashboards without a full instance rebuild. This is a textbook example of why discovery-phase questions about reporting requirements must happen before the instance-sizing and region conversation, not after.
Reference – Google CCAI Docs
