Sales admin settings and the App Settings area

What it does

App Settings is the in-app admin area of Sales Hub where the sales-specific configuration lives — lead and opportunity behaviour, the product catalogue, goals, forecast setup, productivity tools and the Teams and LinkedIn connections. A second area, Sales Insights Settings, holds the standard and premium insights features: sales accelerator, email engagement, relationship intelligence and predictive scoring. Both are reached from the Change area control at the bottom of the sitemap.

Key facts

The unified settings experience is the default in the Sales Hub app. Sales Professional has its own equivalent settings navigation.
Build a custom model-driven sales app instead of using Sales Hub and you get no settings area at all — an admin has to add the settings sitemap area to that app by hand.
The split is deliberate: App Settings for the core sales app, Sales Insights Settings for the AI/insights layer. People routinely hunt in the wrong one.
There's a search box at the top of App Settings that filters by setting name and shows the navigation path to each hit. It keeps your last five searches.
Configuring anything here needs an administration or customisation role — System Administrator or System Customizer. The primary sales roles (Salesperson, Sales Manager) can use the features but not configure them.
Premium Sales Insights features exposed in the settings area still need the matching Dynamics 365 Sales licence behind them; the toggle appearing is not proof of entitlement.
The App Settings landing page surfaces Microsoft's own notifications about new features and settings, which is the closest thing to a change feed you'll get in-app.
Not everything sales-related lives here. Environment-level Dataverse settings — auditing, currencies, duplicate detection, hierarchy security — sit in the Power Platform admin centre under the environment's Settings.

When to use / skip

This isn't optional; it's where you spend the configuration phase of any Sales project. The useful judgment is about scope. On a straightforward Sales Enterprise rollout, plan a deliberate pass through App Settings early — before users touch the system — because several of these toggles change record behaviour that's awkward to unwind once there's data. On projects where the client insists on their own branded app module rather than Sales Hub, budget time for wiring the settings area in, and be honest that you're taking on maintenance every time Microsoft adds a settings page.

The one place to push back is clients who want every insights toggle switched on during UAT "to see what it does". Sales accelerator, predictive scoring and email engagement each change the seller's day-to-day surface. Turn them on one at a time with a reason attached.

Configuration decisions

Sales Hub as-is, or a custom app module — this decides whether you inherit the settings area and Microsoft's future sitemap changes, or own them.
Which insights features are in scope for go-live versus phase two, and who signs off on the seller-facing change each one causes.
Who holds System Administrator in production long term, and whether day-to-day sales admin work can be done with System Customizer plus a targeted custom role instead.
Whether settings work is done directly in production or in a dev environment and migrated — most of these settings do not travel in a solution, so decide early and write it down.
Which environments get the full settings pass: dev, test, UAT and production all need it, and drift between them is the usual cause of "it worked in test".

Gotchas

Configuration you do in App Settings is largely environment-level. It is not carried by solutions the way forms and views are, so a solution import into production is not the end of the job. Keep a written settings checklist per environment.
A custom sales app silently lacks the settings area. Nobody notices until an admin says they can't find product catalogue settings.
Some legacy configuration still lives in the old Advanced Settings web UI or has moved to the Power Platform admin centre. Expect to bounce between three surfaces in a single working session, and expect Microsoft to keep moving things.
Settings pages appear for features the tenant isn't licensed for. Turning one on produces either nothing or a licence error for end users, not a clear message to the admin.
The search box only finds settings that exist in this app's settings area — it won't reach the Power Platform admin centre, so "it's not there" often means "it's not here".

Consultant notes

Do a full screenshotted walkthrough of App Settings with the client's admin during handover. It is the single best hour of knowledge transfer on a Sales project, and it prevents the "we didn't know that was configurable" conversation six months later.
Keep a settings workbook — page, setting, value, environment, who decided it. Regenerate it before every environment refresh, because a copy from production to test will bring some of it and not the rest.
Demo the search box. Admins hate the sitemap and love the search, and it materially reduces support tickets.
Before go-live, log in as a non-admin sales user and confirm nothing you enabled has produced an error banner or an empty pane. Admin-eye testing hides licence gaps.

Worth a re-read whenever Microsoft moves another block of settings into the Power Platform admin centre.