RCS for Business: Access, Roles & Permissions

The brand is the business whose name, logo, and contact information appear in the messaging app. The agent is the programmatic sender that represents that brand. The partner account is the operator’s workspace in Google’s RCS for Business Developer Console. A carrier network is a launch destination that has to approve the agent before eligible users on that network can be reached. Google’s agent guide and launch overview separate these layers.

This separation matters when a company asks “who owns our RCS?” The displayed brand is yours, but the console seats and service-account key may be held by a messaging partner. Google describes aggregators, CPaaS providers, carriers, and RCS solution providers as partner types that build and maintain agents for businesses. A brand employee who approves verification is exercising authority over representation; that does not automatically make that employee a Reader or Manager in the partner’s console. Google’s data-security explanation describes the partner relationship.

For a concrete example, a bank may authorize a partner to operate a support agent. The bank representative confirms the agent is truly the bank’s and that the partner can manage it. The partner’s Manager configures the agent and requests launch on chosen networks. A carrier may review that request. The bank should keep the agent ID, partner ID, and contract contact in its own inventory so a future agency handoff does not depend on one employee’s inbox.

As of November 2026, Google’s partner registration guide begins with an interest form. It asks for an individual Google Account tied to a corporate email, not a group account or Gmail address, for the partner owner. It also collects a technical point of contact. That technical contact is a contact field, not a console permission tier. The partner account’s region and the agent’s hosting region are separate choices; the latter is fixed after creation.

The documented partner-account role table is short and important. Google’s partner-account guide says the creator is Owner, new users can be Manager or Reader, Managers can manage all agents in that partner account, and Readers can view them. These roles are across the partner account, not scoped to one brand agent. A contractor invited as Manager to help one retailer may be able to edit every agent the partner operates.

The brand’s authorized representative and the technical point of contact are named people in the launch process, but Google does not present them as partner-console roles. Keep them in a separate contact inventory. Also distinguish the service-account key from a user seat: a key authenticates API calls even if a person is removed from the Users page.

Open the RCS for Business Developer Console, choose Partner account settings, then go to Users. To add a person, enter the email address and choose Role. Google says the new user receives an email about access. Choose Reader for a person reviewing an agent’s setup and Manager only for a person expected to operate agents across the partner account. Google’s user-management instructions describe the controls.

To change an existing user, find their row, open the three-dot menu, choose Edit role, select the new role, and Save. To remove a person, use the same row menu, choose Remove user, and confirm. Google says the removed user receives an email. Those are console-seat actions; they do not rotate a service-account key the person may have copied into a deployment or had access to in a secret manager.

The Owner has a special recovery rule. Google says a user with the Owner role cannot be removed in that menu; changing or removing the Owner requires RCS for Business support. Do this before the owner’s corporate mailbox or Google Account is disabled. An ops lead who deactivates the departing owner first could delay agent management while the support case is resolved. Keep the partner ID and agent IDs available for that case, since Google’s support instructions ask for them.

If the brand changes agencies, there is a second handoff beyond personnel. The brand should confirm which partner account currently operates the agent, preserve the brand authorization record, and coordinate the transition with Google and both partners. Google’s support guide calls out authorization letters and proof of relationship for ownership changes. A brand contact cannot simply press “Remove user” in an unrelated partner account and expect the agent to migrate.

A partner creates an agent for a brand in the Developer Console using + Create agent. Google asks for brand, agent name, hosting region, billing category, and use case, and says an agent cannot be deleted for security reasons. The hosting region is fixed after creation and is selected for data and latency needs, not for the target carrier; Google says all hosting regions can access carriers worldwide. Google’s agent creation guide makes this an early decision. A mistaken region is more consequential than a cosmetic typo.

Before a first launch, the operator opens the agent’s Verification page, enters an individual brand representative’s contact information, and chooses Update agent verification info. Google says a distribution-list address is not acceptable because an authorized brand person must answer the mandatory authorization request. Supporting documents such as an authorization letter can be uploaded before the launch request. Google’s verification guide says verification information is submitted once per agent, but a carrier may separately contact the brand.

The launch request then goes through Launch > Get started > Select carriers for the agent. The operator supplies the requested use case, message triggers, opt-out behavior, and assets. The brand contact receives the approval email for a Google-managed launch and must respond. The Launch page reports status by carrier, not as one global on/off switch. Google’s launch-approval guide describes these screens and says the agent becomes reachable after a status changes to Launched and propagation completes.

Carrier-managed networks may require a direct agreement. Google’s launch overview also says a Google-managed carrier launch currently requires an earlier carrier-managed launch in the same country. That requirement is per country; a launch in another market does not satisfy it. A team planning a cross-border rollout should map carriers country by country instead of assuming one approval covers every recipient.

Once the agent is verified and launched, Google Messages displays a checkmark next to its name. That badge reflects brand verification, not a guarantee about the content of every future message. Google’s verification guide also describes verification tokens issued by Verification Authorities for certain carrier paths, with future requirements still pending as of its 2026 update. Check the target carrier’s current requirement before promising a launch date.

Google’s partner-account guide says API calls use a service-account key. That key can create and manage brands and agents and send messages or requests as an agent. The guide allows up to ten keys per service account and tells operators to keep each downloaded key private. It is therefore a more powerful access artifact than a Reader seat, and often more important than a human login during an incident.

The console path for initial creation is Partner account settings > Service account > Create key > Create. The browser downloads the key. Put it in a controlled secret store and record which deployment uses it. Never copy it into a support ticket, chat, source file, or analytics export. When a developer leaves, find every application and environment where that developer could read or deploy the key. Removing the developer from Users does not itself prove that a copied key stopped working; test the old integration’s access as part of the revocation plan.

Google’s partner-account page documents key creation but does not give a full per-key revocation procedure in that guide. Work with the partner account operator and Google support to replace and retire exposed credentials; do not claim there is a one-click user removal that revokes every API credential. When changing an operator, create the replacement path, verify that legitimate traffic still works, then retire the old path and check message and webhook activity. Keep a record of who approved the cutover.

Inbound messages and events arrive at a partner-level webhook by default, or an agent-level webhook when configured. Google says an agent-level webhook can override the partner webhook for that agent. The webhook guide requires checking the X-Goog-Signature with the configured client token before accepting an event. A webhook URL is not proof that a request is genuinely from Google. The same guide warns that one failing agent webhook can affect others on a partner account’s shared queue, so an offboarding cutover needs a delivery test across affected agents.

The Developer Console’s Analytics section reports sent, delivered, and read message counts for an agent, with daily UTC updates; Google also offers an export. The agent analytics guide describes the metrics and an eight-day backfill for later delivery and read events. These numbers are useful for noticing a traffic discontinuity after a key or webhook change. They are not a complete record of which employee read a customer’s message.

The Analytics overview also shows agent reputation, spam trend, and traffic limit, according to Google’s overview. A sudden increase in spam reports after a new campaign is a reason to inspect consent and message content with the partner. Avoid treating the dashboard as a substitute for the partner’s own message logs, access logs, and deployment logs.

For an access review, compare four lists: console users and roles; service-account keys and secret-store readers; webhook endpoints and operators; brand contacts and launch approvals. Reconcile these with the partner contract. If an agency engineer is gone but its old key is still deployed in a test environment, that is remaining access. If a brand approver is no longer employed, the next carrier launch may stall even though the existing agent continues sending.

Google’s data-security page says the business can retain conversation data under its own privacy policy and must supply a privacy policy for launch review. This puts a separate duty on the brand and partner to define who can see customer content, how long it is kept, and how a request for deletion is handled. Google’s transport security does not settle those operational decisions.

“The bank approved the brand, so every carrier is live.” Brand authorization is one prerequisite. Google and carriers approve launch requests, and the Launch page shows status per network. Check the actual carrier row before sending a campaign. Google’s launch guide describes the status check.

“Reader means read-only for our one agent.” It means read-only across all agents in the partner account. A provider that operates many brands should decide whether that visibility is appropriate for a brand employee. Google’s role guide does not promise an agent-scoped Reader.

“We removed the employee, so the API is safe.” If the employee could copy a service-account key, the key is a separate path that can send messages and manage agents. Inventory and replace credentials as part of departure. Google’s key description spells out its scope.

“Choose Europe because the campaign targets a European carrier.” Google says hosting region should reflect regulation, business needs, and proximity, and that all regions can reach carriers worldwide. An agent’s region cannot be changed after creation. Google’s agent guide makes the choice explicit.

“A shared inbox address can approve verification.” Google asks for an individual brand representative who can personally confirm the partner’s authority. A distribution list is not accepted for that mandatory request. Google’s verification instructions explain why.

“One country approval covers a second country.” Carrier requirements and the prerequisite for Google-managed launches are country-specific. Before adding a market, review the available networks, contract status, verification-token requirement, and Launch page for that country. Google’s carrier-launch overview provides the current rule.