Google is rolling out a new way to work with people who aren’t on your company’s Google Workspace, and it’s a lot more structured than just “chatting with externals.” The new feature is called guest accounts, and it’s designed to let you bring customers, agencies, freelancers, and vendors into your Workspace world without giving up control over your data or your security posture.

At a high level, guest accounts sit somewhere between a full Workspace user and a one‑off external collaborator. When someone inside your organization starts a direct message or adds an external participant to a Google Chat space, Google can now automatically spin up a guest account for that person under your domain. The guest keeps using their existing email address, but technically, they become a managed user in your environment with a unique account identifier and their own place in your admin console. That’s a big shift from the older model of “random external address in a chat or file,” because it means you can apply policies, see activity, and revoke access in a much more predictable way.

Google is treating these guests as first‑class, but constrained, citizens inside Workspace. By default, all guest accounts are placed into a special “Workspace Guests” organizational unit (OU), which comes with its own baseline security settings instead of inheriting everything from your root OU. Admins can then tighten or relax those controls for guests just like they would for any other group: enforce 2‑step verification, plug guests into context‑aware access, and wrap them in data loss prevention (DLP), access and authentication controls, and external messaging policies. The idea is simple: if someone is touching your docs, chats, or meetings under your domain, they should be subject to the same kind of guardrails as your employees—even if they’re technically “outside.”

From the user’s perspective, Google is trying to keep things familiar, but with clear visual cues. In Chat, guest accounts show up with a teal “external” label, alongside the yellow “external” tag that already exists for people on other Workspace domains. You can @mention guests the same way you do colleagues, and once they’re invited, they can be pulled into Chat, Drive, Docs, Sheets, Slides, and Meet. They don’t get carte blanche, though: they can only be invited to collaborate on existing files—your organization still owns all data, and guests cannot create or own new files in Google Drive. That’s an important nuance for legal and compliance teams who worry about content walking out the door when projects end.

If you’ve used visitor sharing in Google Drive before, guest accounts are a more powerful, admin‑friendly evolution of that idea. Visitor sharing was built around PIN‑based access for people without a Google account and worked well for short‑term, file‑level collaboration. Guest accounts, by contrast, give you something closer to an actual user lifecycle: you can see all guest identities in the Admin console, manage them via APIs, and treat them as a distinct population in your directory. Google even flags them in the Directory API with a dedicated is_guest_user field, and they show up in user.list results, which is handy if you’re syncing data into security tools or HR systems.

On the admin side, Google is clearly pitching guest accounts as a way to unify a bunch of scattered controls you may already be using. The feature ties into your existing external chat settings; if you currently allow users to chat with people outside the company, those same people will now be able to invite non‑Workspace users as guests by default. There are two key levers to know about. First, you can control who’s allowed to chat externally at all, which many organizations already limit by OU. Second, there’s a dedicated guest invitation setting that lets you decide which users or groups can actually send guest invitations, and that defaults to “on” for anyone who can already chat externally. On top of that, the guest OU itself can have its own DLP rules, sign‑in requirements, and access scopes, giving security teams a way to model guests as higher‑risk users without blocking collaboration outright.

One of the more interesting design choices is ownership and scope. Google is explicit that your organization keeps ownership of everything created and shared inside your Workspace domain when you’re working with guests. Guests come in to edit or comment, not to build their own little island of content they control. That aligns with how a lot of businesses already want to operate with contractors and agencies: the work product should live with the hiring company, and access should be revocable when the engagement ends. Combined with existing DLP, audit logging, and access expiry tools, it gives admins a stronger story when auditors or regulators ask how external collaborators are managed.

There are some important caveats that will matter if you’re the person actually configuring this. Guest accounts apply only to non‑Workspace external users; collaboration with other Workspace domains or consumer Google accounts works the way it always has and doesn’t require a guest to be created. If you’ve set up trusted domains to tightly control which external orgs your users can share with, you can now add non‑Workspace domains to that allowlist, effectively saying “we trust partners at this domain, even if they’re not on Workspace.” But there’s a trade‑off: enabling trusted domains disables collaboration with consumer Google accounts, including situations where someone registered a personal Google account with their work email. For organizations that rely heavily on freelancers or very small vendors, that’s a policy discussion worth having before flipping the switch.

On the rollout front, Google is taking a phased approach typical of Workspace launches. Admin controls are rolling out gradually to both Rapid Release and Scheduled Release domains, starting March 26, 2026, and are expected to finish by April 10, 2026. Once those controls are in place, end‑user capabilities—actually inviting and working with guests—will follow in a full rollout between April 13 and April 16, 2026. Business Starter, Standard, Plus, and the Enterprise Starter, Standard, and Plus tiers are all in scope, which covers the bulk of paying Workspace customers. API support for creating guests is slated to arrive in open beta by May 2026, which should make this far more interesting for large organizations and MSPs that automate onboarding and offboarding.

For everyday users, the flow is meant to feel almost frictionless. If your admin allows it, you just add an external email to a Chat DM or space, and the guest invitation goes out automatically. The external person gets an email at their primary address, walks through a sign‑up flow, and then can start collaborating as a guest. Their privileges are limited compared to full Workspace users—think of it as “enough to get work done, not enough to break things”—which lines up with how external messaging and security settings typically work in Chat and Drive today. For people used to hopping into Meet calls or commenting on Docs without a full Google account, this is essentially the more governed, enterprise‑ready version of that experience.

Zooming out, guest accounts are another step in Google’s long‑running effort to make Workspace a hub for hybrid collaboration, not just an internal productivity suite. Over the last few years, we’ve seen features like visitor sharing, more granular external sharing controls, and tighter DLP in Chat and Drive—all aimed at the same problem: your projects rarely stay within the four walls of your domain. Guest accounts formalize that reality by giving security teams a clear way to see and govern everyone who has a foot in the door, while making it easier for end users to just invite the people they need and get on with the work. For many organizations, the real test will be how well this balances security and convenience in practice, especially once the API opens up and guests start being created at scale.