On this page
Before you start
This is one narrow slice of the full deployment guide.
This guide covers only how to target a Haven rollout at one Organizational Unit or one Group, rather than everyone in your domain. If you have not deployed Haven at all yet, start with Deploy Haven with Google Workspace instead — this page assumes you already have Chrome management rights and know which OU or Group you are aiming at.
As with any Haven deployment, this step only installs and pins the extension. It does not add anyone to your Haven organization — that still happens through Haven's own invite or sign in flow, covered in Set up your Haven organization.
If you want pilot users signed in to Haven automatically, that step has a scope of its own: in the Google Admin console's App access control, Haven's sign in app must be marked Trusted for the same OU or Group you deploy to below, and your Haven organization needs a verified domain with automatic enrollment on. The steps are in Turn on automatic sign in — match its scope to the one you choose here.
The most common reason to target one OU or Group is a pilot: prove Haven out on one team's machines, watch it for a week, then move the same policy up the tree to cover everyone. The mechanism below is identical whether that is the goal, or you simply want a policy — like Haven at all — to apply to only part of your organization permanently.
OU or Group?
The Admin console's device policy tree accepts either.
Chrome browser policy in the Google Admin console targets a place in your Organizational Unit tree by default, but a growing set of policies — Haven's extension force install among them — can instead target a Group directly. Pick whichever already matches how your directory is organized.
Use an OU when
- People are already separated by department, office, or device type in your directory structure — Engineering, Contractors, Kiosk Devices
- Settings should flow down the tree: a child OU inherits its parent's policy unless it overrides it
- Moving someone in or out is a directory change made by whoever administers your structure
Use a Group when
- The people you want to target cut across OUs — a cross functional pilot team, or everyone with a company laptop regardless of department
- Policy should apply directly to members with no inheritance from anywhere else in the tree
- Adding or removing someone should be lightweight, and can often be delegated to a team lead
Not sure which you will want long term? Start with whichever is faster to stand up for a pilot — usually a Group, since you can create one and add a handful of pilot users to it in minutes, without touching your OU structure.
The value you need
Everything below runs off this one identifier.
Scope it in the Admin console
The same screen as a full rollout — the only difference is what you select in the tree.
-
Sign in to the Google Admin console with an account that has Chrome management rights, then go to:
Devices › Chrome › Apps & extensions › Users & browsers -
In the left hand tree, select the specific Organizational Unit you want Haven deployed to — or switch the selector to Groups and choose the Group instead.
Do not select a parent OU that also contains people you are not ready to deploy to yet. Settings apply to everyone below the unit you select unless something lower in the tree overrides them.
-
Click the + button in the lower right and choose Add from Chrome Web Store.
-
Search for Haven, or paste the extension ID above. Confirm the listing shows publisher starthaven.com before selecting it.
-
In the Haven row for that OU or Group, set Installation policy to:
Force install + pin to browser toolbarPlain Force install also works, but leaves the icon collapsible into the puzzle piece menu — pin it so pilot users see it without hunting for it.
-
Leave Permissions at the default unless your security review requires otherwise, then click Save in the top right.
If you also manage Chrome extensions through a policy file (Intune, Jamf, an RMM, or raw ExtensionSettings JSON), make sure that configuration does not also target the same OU or Group. Two policy sources aimed at the same population can issue conflicting instructions for which devices get Haven.
Confirm only that scope got it
Check a machine inside your target, and — just as importantly — one deliberately outside it.
- Inside the target: open
chrome://extensions. Haven appears, switched on, labelled Installed by your administrator, with no Remove button — and the icon is pinned on the toolbar, not tucked in the puzzle piece menu. - Inside the target: open
chrome://policy. AnExtensionInstallForcelistorExtensionSettingsentry lists the Haven extension ID. Click Reload policies if it has not appeared yet. - Outside the target: a machine in a sibling OU, or a colleague who is not in the Group, shows no Haven entry at all in either place — proof the scope is actually holding, not quietly covering more than you selected.
Widen the scope later
There is no re-deployment to do.
When your pilot is done, move the same policy up the tree rather than repeating the steps above. For an OU, select the parent OU — or the root — and apply the same Haven force install setting there; child OUs that had no override of their own pick it up automatically. For a Group, either add more members to the existing Group, or add the same Haven force install entry to the OU or Group that covers everyone else.
If your pilot was also running with enforcement in monitor only, this is a natural point to turn on enforcement for the group you are widening to.
Troubleshooting
The four things that come up most often once a rollout is scoped.
Haven installed on some machines in my Group but not others
Group based Chrome policy only reaches a signed in, managed browser profile on your Workspace domain. A personal Chrome profile, or a machine where the user has not signed in with their Workspace account yet, will not pick it up until they do.
I moved someone into the OU and they still do not have Haven
OU membership changes and Chrome policy refreshes are two separate delays. Confirm the directory move actually saved, then give the browser a policy refresh — open chrome://policy on that machine and click Reload policies rather than waiting out the usual few minutes.
A child OU is getting Haven and I only meant to scope the parent
That is inheritance working as designed — a child OU with no override of its own always picks up its parent's policy. If you need that one child excluded, add an explicit override at the child OU with Haven's installation policy set to Allow install (not forced) or Block, depending on whether you want it optional or absent there.
Haven installed, but pilot users are not signed in automatically
Automatic sign in is scoped separately from the install. Check that Haven's sign in app is marked Trusted in App access control for the same OU or Group you deployed to, that the affected Chrome profile is signed into a Workspace account inside that scope, and — with Haven — that your organization has a verified domain with automatic enrollment on. Until all three hold, those users sign in by hand or by invitation; Haven never blocks them.
Still stuck?
Tell us the symptom, whether you targeted an OU or a Group, and what you see at chrome://policy on an affected machine, and we will help you sort it.