New administrators usually discover the console the hard way: a ticket arrives, they open the portal, and the left navigation offers fifteen sections with no indication of which one owns the setting in question. This tour maps the territory once, so later chapters can reference sections without re-explaining them.
Who Gets In
Access is role-based: a global administrator, a dedicated collaboration administrator, and read-only support roles are the typical tiers. Grant the narrowest role that lets someone do their job — support staff who only diagnose problems need read-only, and read-only prevents the 2 a.m. well-intentioned outage.
Dashboard: The Morning Glance
The landing page summarises active users, call quality trends and service health. Its real value is anomaly detection: a sudden dip in call quality or a spike in active users after a licence change tells you something before anyone files a ticket. Thirty seconds each morning is enough.
Team and Channel Management
This section lists every team with its privacy type, owner and member count. Three views earn their keep: teams without owners (an orphan risk), private teams (a compliance question), and megateams above a few hundred members (a performance and governance question). Team templates also live here, letting you provision standardised structures per department.
Users: The Policy Lens
Open any user and the policies tab lists every policy type currently applied to that person, including whether assignment came directly or through a group. When a user reports "I cannot do X but my colleague can", this view resolves it in seconds. It is the single most underused screen in the console.
Meetings, Messaging, and Calling
Each capability area follows the same pattern: a global default policy plus named policies you assign to people or groups. Meeting policies govern recording, lobby and anonymous join; messaging policies govern editing, deleting and rich-content features; calling policies govern dialling scope and call queues. The mental model — default floor, named exceptions — is identical across all three.
Where settings secretly live elsewhere
Some controls that feel like collaboration settings are owned by neighbouring systems: identity and sign-in conditions live in the identity administration, retention and legal hold live in the compliance centre, and licence capabilities live in the billing portal. When a setting is missing from this console, it is usually not missing — it is someone else's console.
Apps and Permissions
The apps section decides which third-party and custom apps may exist in your tenant, through app permission policies, and which get pinned for users, through setup policies. The factory default typically allows everything; most organisations tighten this before wide rollout, because every permitted app is a potential data path out of your tenant.
Org-Wide Settings: The Two That Matter Most
At the bottom of the navigation sit tenant-wide switches that no individual policy can override. Two dominate governance discussions: external access (whether your users may federate with other organisations' tenants at all) and guest access (whether outsiders may be added into your teams). Configure both deliberately before rollout; changing them later is a communication project, not a click.
Reports and Audit Trails
Usage reports show adoption and activity; the audit log — housed in the compliance centre — records administrative and user actions with timestamps. Know where each lives before an incident, because during an incident is the wrong time to learn the difference between "how many people used it" and "who changed this setting".
With the map in hand, the next chapter tackles the mechanism that makes policy management scale: assigning policies to groups instead of chasing users one by one.
