Admin-Install vs User-Install Marketplace Apps

Every day, employees across Australian businesses open the Google Workspace Marketplace and connect apps to their accounts without giving it a second thought. A project manager installs a task board. A sales rep links their CRM. Someone in accounting connects a PDF tool that claims to save them ten minutes a week. Each click feels harmless in isolation. Collectively, they create a patchwork of third-party integrations that most IT teams have no visibility into, no policy governing, and no process for reviewing.

The Google Workspace Marketplace supports two distinct installation modes: admin-managed deployments, where IT controls exactly which apps are available and to whom, and user-initiated installs, where individual employees can add apps directly from the Marketplace. These two modes carry fundamentally different risk profiles, different governance implications, and different operational consequences. Choosing the right approach — or more often, choosing the right combination — is one of the most consequential app governance decisions an IT admin makes.

This guide explains how each installation mode works in the Admin Console, when to use each one, and how to build a policy that gives your team access to the tools they need without sacrificing the oversight your organisation requires.

What this guide covers:
- How admin-install and user-install modes work in Google Workspace
- The security and compliance implications of each approach
- How to configure Marketplace deployment policies in the Admin Console
- When to use admin-install vs when user-install is appropriate
- Building a practical policy framework for Australian SMBs

Understanding the Two Installation Modes

Before you can build a policy, you need to understand exactly what you are dealing with. The Google Workspace Marketplace installation model is more nuanced than a simple on/off switch.

Admin-Install: IT-Managed Deployment

Admin-install means an IT administrator deploys a Marketplace app across the organisation — or to specific organisational units — through the Admin Console. Users receive the app automatically without having to find it, request it, or grant permissions themselves.

When an admin installs a Marketplace app on behalf of users, several things happen that differ significantly from a user-initiated install:

• Permissions are granted at the domain level. The admin reviews and accepts the OAuth scopes on behalf of the organisation, not the individual user. This means the app's access is controlled, documented, and consistent across every user it is deployed to.
• The app appears automatically in users' accounts. It shows up in relevant Google Workspace products (a Docs add-on appears in Docs, a Gmail add-on appears in Gmail) without any action from the user.
• The deployment is scoped to specific OUs. You can push an app to your sales team without making it available to finance, or deploy a school administration tool to teachers without it appearing for students.
• The admin can remove it centrally. Uninstalling an admin-deployed app removes it from every user in scope simultaneously. There is no dependency on individual users to take action.

Admin-install is what IT governance looks like in practice: centralised, intentional, and auditable.

User-Install: Employee-Initiated Connections

User-install is what happens when an employee browses the Marketplace independently, finds an app, and clicks "Install." In a default Google Workspace configuration, this is completely unrestricted. Users can connect any app, grant any permissions that app requests, and IT will have no notification that it occurred.

When a user installs a Marketplace app on their own:

• The user grants permissions, not the admin. The OAuth consent screen shows the user what the app is requesting, and the user decides whether to allow it. Most users click "Allow" without reading the permissions.
• The install is scoped to that individual user. Other users on the same team do not get the app unless they install it themselves.
• Visibility is limited. The install does not appear in most admin dashboards by default. You need to actively look for it in the API controls audit log.
• Removing it requires action from the user or a domain-level revocation. You cannot silently remove a user-installed app in the way you can an admin-deployed one without revoking its OAuth access entirely.

User-install is what shadow IT looks like in practice: decentralised, unplanned, and largely invisible.

Why the Distinction Matters for Security and Compliance

The difference between these two modes is not just administrative preference. It has direct implications for your security posture and your compliance obligations under Australian law.

Data Access Without Oversight

Under the Privacy Act 1988 and Australian Privacy Principle 11, your organisation is required to take reasonable steps to protect personal information from unauthorised access. When an employee installs a Marketplace app and grants it access to Drive files containing client records, invoices, or staff information, that third party becomes an unauthorised data processor unless your organisation has reviewed and sanctioned the relationship.

"We did not know about it" is not a defence in the context of a Notifiable Data Breach. If a third-party app your employee installed causes a data breach, the Office of the Australian Information Commissioner will ask what systems you had in place to control and monitor third-party access to personal information. An unrestricted user-install policy makes that answer very difficult.

OAuth Scope Sprawl

The practical risk of unrestricted user-install is OAuth scope sprawl: a situation where dozens of apps have been granted access to your organisation's data with no central registry, no review, and no expiry. Each app represents a potential attack vector. If a Marketplace app vendor suffers a breach, every user who granted that app access is affected — and if the app had broad scopes like full Drive access or full Gmail access, the blast radius is significant.

Admin-install closes this loop. You review the scopes once, make an informed decision, deploy centrally, and maintain a record. When you need to revoke access, you do it in one place.

Consistency of Configuration

When multiple users independently install different versions or configurations of the same class of tool, you create inconsistency. Your sales team might have four different CRM sidebar apps installed across twelve users. Each has different permissions, different data handling practices, and different vendor relationships. Admin-install ensures that when your organisation uses a tool, everyone uses the same vetted version with the same approved configuration.

Configuring Marketplace Policies in the Admin Console

Google Workspace provides several layers of control for managing how Marketplace apps can be installed. Here is how to configure them.

Step 1: Set the Domain-Level Marketplace Access Policy

1. Sign in to the Google Admin console at admin.google.com with a Super Admin account.
2. Navigate to Apps > Google Workspace Marketplace apps > Settings.
3. Under Marketplace settings, you will see the core access policy. You have three options:
4. Allow users to install and run any app from the Marketplace: The default setting. Provides no restrictions. Any user can install any app at any time.
5. Allow users to install and run only apps from the approved list: Restricts users to apps that have been explicitly approved by an admin. Users cannot install unapproved apps. They may see a request option depending on your configuration.
6. Do not allow users to install or run apps from the Marketplace: Completely blocks user-initiated installs. Only admin-deployed apps will be available.
7. Select the option appropriate to your risk posture and click Save.

Recommendation for most Australian SMBs: Start with "Allow users to install and run only apps from the approved list." This blocks unsanctioned installs while preserving your ability to approve apps that meet your criteria. It also motivates users to go through your request process rather than working around controls.

Step 2: Build and Maintain an Approved App List

If you choose the approved-list approach, you need to populate it.

1. Navigate to Apps > Google Workspace Marketplace apps > Apps list.
2. Click Add app and search for the app by name or by its Marketplace URL.
3. Review the app's OAuth scopes before adding it. The Admin Console will display what permissions the app requests during domain-level installation.
4. Choose the installation type:
5. Admin install: Deploy the app automatically to specific users or OUs.
6. Allow users to install: Add the app to the approved list without deploying it. Users can install it themselves, but only apps on this list are permitted.
7. Specify which OUs the app applies to. You can grant access domain-wide or restrict it to specific teams.

Step 3: Configure Per-OU Exceptions

One of the most useful features of the Marketplace policy system is its support for organisational unit overrides. You do not need a single policy that applies uniformly to everyone.

A practical configuration for many Australian SMBs looks like this:

• Domain-wide policy: Allow approved list only
• IT team OU: Allow any Marketplace app (so your IT staff can evaluate tools without requesting their own approval)
• Finance OU: Do not allow user installs at all (only admin-deployed apps)
• General staff OU: Allow approved list with request option enabled

To configure OU-level overrides:

1. Navigate to Apps > Google Workspace Marketplace apps > Settings.
2. In the left sidebar, select the organisational unit you want to configure.
3. Change the setting and choose Override (rather than inherit from parent).
4. Save the OU-specific setting.

Step 4: Admin-Deploy Approved Apps to Relevant OUs

For apps your team needs to use consistently, deploy them rather than just approving them.

1. Navigate to Apps > Google Workspace Marketplace apps > Apps list.
2. Select the app you want to deploy.
3. Click Admin install app.
4. Choose the target OU or the entire organisation.
5. Confirm the OAuth scopes and click Install.

Users in the target OU will receive the app automatically. For add-ons (Gmail, Docs, Sheets, etc.), the add-on appears in the relevant product without any action from the user. For web apps and standalone tools, the app appears in the Workspace app launcher.

When to Use Admin-Install vs User-Install

The right approach depends on the nature of the app and the needs of your team. Use this framework to guide your decisions.

Use Admin-Install When:

• The app is a business-critical tool. If your entire sales team needs a CRM sidebar, or your operations team depends on a project management integration, admin-install ensures uniform deployment and removes friction for users.
• The app handles sensitive data. Any app that will access Drive files containing personal information, Gmail threads with client data, or calendar events with confidential meeting details should be admin-deployed so the permission grant is documented and controlled.
• You need consistent configuration. If the app has settings that should be standardised across your organisation (data residency, encryption, logging), admin-install with pre-configuration is the only reliable way to achieve this.
• The app serves the whole organisation or a defined team. When the scope of users is known and stable, admin-install is operationally cleaner than expecting users to install it themselves.
• Compliance requires auditability. If your industry is regulated (finance, health, legal, government), having a documented record of exactly which apps have domain-level access, with what scopes, and to which users is essential. Admin-install provides this; user-install does not.

Use Approved-List User-Install When:

• The app serves individual productivity needs. A grammar checker, a personal calendar tool, or a PDF viewer that only accesses data the individual user explicitly provides is lower risk and well-suited to user-initiated install from an approved list.
• App selection varies by role or preference. If your team has legitimate reasons to choose between several equivalent tools, maintaining an approved list lets you vet the options while giving users agency.
• You want to reduce IT overhead for low-risk tools. Not every app warrants a deployment project. An approved-list approach lets you pre-screen tools without requiring admin action for each individual install.

Avoid Unrestricted User-Install When:

• You handle personal information. Under the Privacy Act, unrestricted third-party access to personal information without oversight is difficult to defend.
• You are working toward Essential Eight compliance. Application control is a core Essential Eight strategy. Unrestricted user-install directly conflicts with this requirement.
• You have had a data incident. If your organisation has previously experienced a data breach or near-miss involving a third-party app, removing unrestricted user-install is one of the most immediate risk reduction actions you can take.

Building Your App Governance Policy Document

Controls without documented policy are difficult to maintain and impossible to enforce consistently. Here is what a practical app governance policy should cover for an Australian SMB.

Policy Statement

Define the intent clearly. For example: "All Google Workspace Marketplace applications must be reviewed and approved by IT before deployment. Only approved applications may be installed by users. Applications that access personal information, financial data, or internal communications must be deployed by an administrator."

Scope

Specify who the policy applies to: all employees, specific teams, contractors, part-time staff. Define whether it covers both Workspace Marketplace apps and OAuth-connected third-party tools accessed via browser (the latter falls under your API controls policy, which should be treated as a companion document).

Request Process

Describe how employees request a new app. A simple Google Form works for most teams. Include:
- App name and Marketplace URL
- Business justification
- Number of users who will need access
- Data types the app will access
- Required timeline

Commit to a response time. Forty-eight business hours for standard requests is achievable for most IT teams and reasonable for users.

Evaluation Criteria

Document the criteria used to approve or deny apps:
- OAuth scopes requested versus those actually needed for the stated function
- Publisher identity, reputation, and security certifications (SOC 2, ISO 27001)
- Privacy policy compliance with APP 8 (cross-border data transfer) and APP 11 (data security)
- Google Marketplace verification status
- Active maintenance and support availability

Review Cadence

Approved apps should be reviewed quarterly. Remove access for apps no longer in active use. Check for changes to vendor ownership, privacy policy, or security posture. Revoke and replace any app where the vendor has had a breach or significant security incident.

Offboarding Requirement

When an employee leaves, include a step in your offboarding checklist to review and revoke any Marketplace apps they installed individually. Admin-deployed apps are managed centrally and do not require individual action, but user-installed apps that were approved on a case-by-case basis need to be audited.

Affiliate & Partner Programs

Setting up the right Marketplace governance policy is most effective when you are running the right tier of Google Workspace. The advanced API controls, organisational unit management, and security investigation tools discussed in this guide are available on Business Standard, Business Plus, and Enterprise plans.

• Google Workspace Referral Program: https://referworkspace.app.goo.gl/ — Get started with or upgrade to a Google Workspace plan that includes the full Admin Console controls covered in this guide. Our referral link gives you access to current Google Workspace promotions for Australian businesses.

Wrapping Up

The admin-install vs user-install question is not really a technical decision. It is a governance decision that reflects how seriously your organisation takes its responsibilities around data access, compliance, and operational consistency.

Unrestricted user-install is not a neutral default. It is an active choice to let employees make data-access decisions on behalf of your organisation without oversight. For most Australian SMBs operating under the Privacy Act 1988, that is a posture that is difficult to justify and even harder to recover from when something goes wrong.

The good news is that Google Workspace gives you the tools to do this properly without making life difficult for your team. An approved-list policy with a responsive 48-hour turnaround for app requests respects both your security obligations and your employees' need to get work done. Admin-deploying your standard toolset ensures that business-critical apps are available to everyone who needs them, with consistent permissions and a documented approval record.

Start with three actions this week. First, navigate to Apps > Google Workspace Marketplace apps > Settings and review your current Marketplace access policy. If it is set to allow any app, change it. Second, audit the apps currently connected across your organisation using the API controls dashboard and the OAuth token audit log. Third, draft a one-page app request process and share it with your team before you change any settings, so users know how to get the tools they need through the right channels.

The goal is not to block your team from useful tools. The goal is to make sure that every tool your team uses has been reviewed, approved, and documented — and that the access it has to your organisation's data is proportionate to the value it delivers. That is what good app governance looks like.

Need help with your cloud migration? Contact our team for a free consultation.