Salesforce admin procedures at PWG
Salesforce admin procedures at PWG
Section titled “Salesforce admin procedures at PWG”Status: draft. The procedures below describe how the org works today based on configuration in the production org. Hand-off steps and ownership still need to be confirmed with the admin team.
User provisioning
Section titled “User provisioning”Provisioned via Entra ID SCIM through
aad.provision@pwg.com.au. New hires added to the Salesforce Entra
group are created as users automatically. Deactivation also flows
from Entra.
Manual user creation is exceptional. Use it only for integration
users (e.g. automation@pwg.com.au) or when Entra SCIM cannot
model the role (e.g. external consultants). For integration users,
add the specific Permission Set — never edit a human Profile.
Permission model
Section titled “Permission model”The org uses Permission Sets over Profiles.
- 336 Permission Sets (72 custom), organised into 21 Permission Set Groups.
- 56 profiles. 26 are empty (46% of profiles) — historical artefacts.
- 18 custom Permission Sets are empty and are the first cleanup candidate. Total including managed/empty: 192.
- 22 Permission Sets and 11 Profiles grant
ModifyAllData,ViewAllData, or admin-like combinations. Seeanalysis/security-*.md.
Profiles are used for baseline licences only.
Sandbox refreshes
Section titled “Sandbox refreshes”TODO — document the current refresh cadence, who approves, and the post-refresh checklist (sandbox-specific named credentials, muted email deliverability, integration user repointing).
Deployments
Section titled “Deployments”TODO — clarify current deploy tooling (change sets vs SFDX
source deploy), approval path, and rollback approach.
Data loads
Section titled “Data loads”- Bulk inserts/updates run through
dataloader.ioor the Salesforce Data Loader. Both are configured as Connected Apps; use the integration account, not a human user. - Never update production SQL-style via direct tooling — data changes belong in a repeatable script, reviewed, and ideally scheduled through a Connected App with an audit trail.
Queue hygiene
Section titled “Queue hygiene”- Inactive queue holds 1,505 open tasks (948 overdue) as of
2026-04-21. This is the largest single contributor to task fatigue
in the org. Monthly triage recommended — see
analysis/task-fatigue-*.mdfor the method. - Active users with > 150 open tasks are flagged in the same report. Surface to their team lead, not directly to the adviser.
Field history tracking
Section titled “Field history tracking”- Opportunity → StageName was enabled on 2026-04-24 (not retroactive). Dwell-time per stage is measurable from that date forward.
- When adding a new field to tracking, prefer enabling for StageName-like fields (status/stage) on Opportunity, Case, and Lead first. Limit is 20 tracked fields per object.
API limit monitoring
Section titled “API limit monitoring”analysis/api-usage-{date}.mdis regenerated on demand viamcp-server/scripts/analyse-api-usage.ts. Review monthly.- The 97%-consumer finding on
aad.provision@pwg.com.auis benign (manual bulk updates, not runaway sync). If another user ever exceeds 10% without explanation, investigate before it crowds out the org.
Monthly admin checklist
Section titled “Monthly admin checklist”- Run
scripts/run-audits.tsfrommcp-server/— produces freshmisconfig-,security-,performance-,recommendations-,task-fatigue-, andprocess-bottlenecks-reports inanalysis/. - Triage any new High recommendation in the recs report.
- Review inactive-queue task count — delta vs previous month.
- Check Opportunity stage dwell times (once history tracking has 30+ days of data — from ~2026-05-24 onward).
- Regenerate documentation if metadata has changed: see
docs/generated/README.md.
Further reading
Section titled “Further reading”docs/generated/security/INDEX.md— full security inventory.analysis/recommendations-*.md— prioritised admin backlog.mcp-server/docs/connected-app-setup.md— how the MCP integration user is configured; the pattern generalises to any server-to-server integration.