Profiles

A profile (a permission set, in platform terms) is the bundle of permissions assigned to a user. It controls what they can create, see, edit and delete across the CRM.

Permission sets are explicit-allow only: if an object is not listed in a set, holders of that set cannot touch it — not even an administrator. There is no implicit "everything else is readable" rule.

The six built-in profiles

What each profile can do

👑 System Administrator

• Full create/read/edit/delete on every object in the CRM
• View All and Modify All on every object — bypasses record-level sharing
• Configures the system: objects, fields, profiles, sharing, automation, AI skills

⚠️ Use sparingly — typically 2–3 people per organisation.

📈 Sales Manager

• Org-wide read and write on leads, accounts, contacts, opportunities, quotes and tasks — a manager works any rep's record, not just their own
• Create and edit contracts, products and campaigns (deleting them is an admin action)
• Full control of opportunity and quote line items, so pricing on any rep's deal can be fixed
• Read cases, knowledge articles and campaign members
• Forecasts: reads every rep's snapshot and adjusts the committed number — the forecast is the manager's own deliverable
• Cannot see a deal another user flagged Private (see Sharing & security)

💼 Sales Representative

• Create, read and edit their own leads, accounts, opportunities, quotes and tasks
• Contacts: the contacts on accounts the rep can see — their own, plus every account a territory rule or manual share put in reach. Contact is Controlled by Parent, and that derivation follows the account's sharing (see Sharing & security, Controlled by Parent, in practice)
• Opportunity and quote line items — full control, which is what the "Products" related list and quote building need. Controlled by Parent again, so this reaches the lines of the deals and quotes the rep can see, and no others
• Read the product catalog, campaigns, campaign members and knowledge articles
• Read their own forecast snapshots (they are written by the nightly forecast job, never by hand)
• Read their own contracts and cases; deleting is a manager privilege (their own tasks excepted)

🎧 Service Agent

• Create, read and edit cases and tasks in their own queue; critical cases reach the wider service team through the escalation sharing rule
• Read accounts, contacts and leads org-wide — a ticket is meaningless without the customer behind it. Reading is the whole of it: an agent who opens a customer's contact to correct a phone number can save it only if that contact is one they both own and created, which a contact that came in with the account never is (see Why "org-wide" describes reading, not writing)
• Knowledge articles: read every article and author or revise them (the draft → in review → published lifecycle is enforced by the KB flow, not by permissions). Archiving is an admin action
• Read the product catalog
• No access to opportunities, quotes or forecasts

📣 Marketing User

• Leads: create them, read every lead in the org, and edit the ones they own and created — org-wide read does not carry org-wide editing (see below)
• Contacts: read every contact in the org. Creating one is refused in practice — a contact is master-detail under its account, so inserting one requires edit access to that account, and this profile holds no account editing anywhere. Editing is the same owner-and-creator gate as leads
• Campaigns and campaign members: create, and edit any of them — these two objects carry a row-level rule written for this profile, which is what lets a marketer work a campaign a colleague planned and update members the enrollment flow created. This is what the "Add to Campaign" action writes
• Read accounts and opportunities org-wide, for campaign→pipeline ROI (a deal flagged Private stays hidden)
• Read knowledge articles
• Cannot delete records

🌐 Guest (Public Forms)

• Insert only on leads and cases, through the public Web-to-Lead / Web-to-Case forms
• No read access to anything. Every other object — including public-audience knowledge articles — is denied

Why "org-wide" describes reading, not writing

A profile's object grant says what a user may do. Whether a save actually lands is decided a second time, per record, by the platform — and today that second gate is narrow: a user updates a record only when they are both its owner and its creator. Org-wide read (View All) does not widen it; it is a read scope and never grants a write. This is why the bullets above say, per object, whether editing reaches any record or only your own.

The exception is authored deliberately, one object at a time: a row-level rule on the object can open updates to every holder of a profile. This app ships two, both on the Marketing User set — campaigns and campaign members — because enrolling and tracking members is teamwork on rows the enrollment flow created, not the marketer. Anywhere no such rule exists, "edit" means the records you own and created, whatever the read scope says.

Field-level security

Profiles also mask individual fields. What ships today:

A masked field is blank everywhere — list views, reports, the API and the AI Copilot alike. A sales rep opening a case will not see the service team's internal notes.

Assigning a profile

1. Go to Setup → Users.
2. Open the user record.
3. Select the Profile from the dropdown.
4. Save — the change takes effect immediately.

To grant extra permissions on top of a user's base profile, assign an additional permission set ("extra hat") rather than editing the base one — sets are additive and union-merged.

Cloning profiles

If a built-in profile is almost right but needs tweaking:

1. Setup → Permission Sets — the screen is called Permission Sets; Setup has no Profiles entry.
2. Open the permission set and click Clone.
3. Rename (e.g. "Senior Sales Rep").
4. Adjust permissions.
5. Save and assign to users.

⚠️ Do not modify built-in profiles — clone them. Updates to HotCRM may reset built-in profile settings.

What's in a profile

Profile vs position vs sharing — what's the difference?

• Profile (permission set) = what you can do — the verbs: create, edit, delete, and on which objects.
• Position = which group you belong to, used to hand out sharing grants. Positions are flat: there is no hierarchy, so nothing rolls up automatically from a manager to a director.
• Sharing rules = the exceptions — "everyone in the EU territory can edit EU accounts", "the service director can see every critical case".

Both must allow access: the profile decides whether you may read opportunities at all, sharing decides whose.

See Sharing & security for the position + sharing side.

Tips for admins

• ✅ A new object needs a grant. Nothing is readable until a permission set names it — a missing grant looks like a broken screen, not a permission error.
• ✅ Start with built-in profiles — don't customise unless necessary.
• ✅ When in doubt, clone rather than modify.
• ✅ Audit profiles quarterly — when people change jobs, their profile often doesn't.
• ✅ Limit System Administrator to 2–3 people maximum.

Tips for users

If you can't do something you think you should be able to do:

1. Check your profile (top right → your name → Profile).
2. Ask your admin whether that profile grants the object at all.
3. If the profile is right but a specific record is missing, it's a sharing question, not a profile one.