Why start with one page
Most Google Workspace tickets come in as "it doesn't work". Fixing them quickly means knowing which layer is broken. In this level you build a mental map you can sketch on a whiteboard. Every later lesson hangs off that map.
About this course. LevelUpWith is independent of Google. This course is not affiliated with Google or endorsed by it, and it reproduces none of Google's documentation. Google's own help pages now live on knowledge.workspace.google.com. When we give you a console path, we say where it comes from and the date we checked it. Every path in this level was checked on 2 November 2026. Google moves admin screens and renames menus, so check a path again before you rely on it on a live tenant. If something is in preview or we couldn't confirm it, we tell you.
What the user sees
Your user sees apps, not infrastructure:
- Gmail: their mailbox
- Calendar: meetings, rooms and free/busy
- Drive: their files and shared drives
- Meet: video calls
- Chat: messages and spaces
They sign in once with an address like jo@example.com, and each app either works or doesn't. They don't know about the layers underneath. You need to.
What sits behind it
Think of a block of flats. The tenant (Google's term is your Google Workspace account) is the building. The primary domain is the street address on the deeds. The directory is the list of residents. A licence is a resident's key fob. Service settings decide which doors that fob opens.
ONE-PAGE MAP (sketch this on a whiteboard)
Tenant (the organisation's Workspace account)
├── Domains
│ ├── Primary domain example.com <- billing and company logo are tied to it
│ ├── Secondary domain example.co.uk <- separate users, each a paid account
│ └── User alias domain example.net <- extra address for EVERY user, no extra cost
├── Directory jo@example.com <- the user record: name, status, org unit, groups
├── Licences jo has a Workspace licence? <- no licence, no core apps
├── Service settings Gmail/Drive/Meet/Chat ON or OFF per organisational unit
└── Admin console admin.google.com <- where admins read and change all of the above
User's day: sign in -> directory record -> licence -> service ON -> app works
Three domain facts trip people up. Each one was checked against Google's page "Add a user alias domain or secondary domain" on 2 Nov 2026:
- A secondary domain holds different users. Each one gets their own account and mailbox, and each account is paid for (Education Fundamentals and Nonprofit editions are exceptions). A tenant can have up to 599 secondary domains.
- A user alias domain gives every user a second address. For example,
jo@example.netdelivers tojo@example.com. There is no per-user cost, and a tenant can have up to 20 of them. - Domains are managed at Menu > Account > Domains > Manage domains in the Admin console.
Gotcha: some features, such as the billing address and the company logo, are tied only to the primary domain. Don't promise a user at a secondary domain their own logo.
Walkthrough: tracing one user
A ticket arrives: "Jo at example.com isn't getting external email." Before you open any admin screen, run a read-only check from your own machine to confirm that mail for the domain is routed to Google at all:
# Read-only: ask public DNS where mail for the domain is delivered
nslookup -type=mx example.com
# Typical output for a domain set up with Google's current single-record method:
# example.com MX preference = 1, mail exchanger = smtp.google.com
#
# Older tenants often show the legacy set instead (aspmx.l.google.com and others).
# Google says that set still works.
# If you see ANOTHER provider's servers here, mail never reaches Gmail.
# Then it isn't a licence or a Gmail setting, and the domain owner or DNS team needs to know.
Next, walk the map from left to right. Does Jo's directory record exist and is it active? Does Jo have a licence? Is Gmail turned on for Jo's organisational unit? The next few levels show you how to read each of these safely. For now, notice the order: identity, then licence, then service setting, then the app. A failure at any step stops everything to its right.
Four layers behind "it doesn't work"
When a ticket lands, ask how widespread the problem is. The spread usually points to the layer.
TRIAGE HEURISTIC: who is affected?
1 user, every app -> ACCOUNT layer (suspended, password, sign-in problem)
1 user, core apps gone -> LICENCE layer (licence removed, or never assigned to a new starter)
A team or department, -> SERVICE SETTING (service turned OFF for their
one app organisational unit)
Many users, many firms, -> GOOGLE OUTAGE (check google.com/appsstatus,
same app the Workspace Status Dashboard)
Service settings work by organisational unit. On Google's page "Turn a service on or off for Google Workspace users" (checked 2 Nov 2026), the setting sits at Menu > Apps > Google Workspace > Service status, where it can be inherited from the parent unit or overridden. That's why one department can lose Chat while everyone else keeps it.
Best practice: check the Workspace Status Dashboard early. It's free and takes ten seconds. If Google is reporting an incident for Meet, don't spend an hour rebuilding a user's profile.
Trade-off: the heuristic tells you where to start looking. It doesn't prove the cause. An outage can hit one region only, and a user can have two problems at once. Confirm the cause before you write it in the ticket.
What support does with this map
As first or second line support, you mostly read. You read the user's record, their licence, and the service setting that applies to them, and you explain what effect it has. Designing tenant-wide policy is out of scope for this course. If the cause is a policy decision, you escalate it with evidence rather than change it yourself.
Key takeaways
- Users see apps. Behind them sit the tenant, its domains, the directory, licences and service settings, all managed in the Admin console at admin.google.com.
- A secondary domain holds separate paid users. A user alias domain gives every user an extra address at no extra cost.
- The dependency chain runs: sign-in, then directory record, then licence, then service turned on, then the app works.
- How widespread the problem is points to the layer: one user means account or licence, one team means a service setting, many organisations means a Google outage.
- This course is independent of Google, reproduces none of its documentation, and dates every console path. Check paths again on knowledge.workspace.google.com.