Profiles, Roles & Sharing in a REDA Org
REDA hands you permission sets — but what about profiles, the role hierarchy, and sharing rules? Those three are pure Salesforce platform mechanics that REDA does not own or ship, so the how-to for each points to Salesforce's own documentation. What this article makes clear is the division of labor: REDA controls which features a person can use, while profiles, roles, and sharing control the baseline access and who sees whose records — and those you design yourself. After reading, you'll know exactly what REDA hands you versus what you still have to build.
Access you'll need. Salesforce administrator rights — Manage Profiles and Permission Sets, Manage Roles, and Manage Sharing. All are org-side; no REDA permission set grants any of them.
Two different jobs
It helps to name the two layers cleanly, because REDA owns one and you own the other:
- Feature access — can this person use leasing, billing, bookings, inspections? REDA delivers this entirely through its permission sets (see Creating Users & Granting REDA Access).
- Baseline access and record visibility — can this person open Accounts and run reports at all, and whose records can they see? This comes from profiles, the role hierarchy, and sharing settings — which REDA does not ship. You build them.
Profiles in a REDA org
A profile is the base layer of a user's access — it governs login, standard objects, reports, flows, and default app and tab visibility. In a REDA org the profile carries a specific, deliberate load, because REDA's permission sets leave the baseline entirely to the profile. That baseline includes:
- Standard objects — Account, Contact, Task, and Event access. No REDA set grants any of these.
- Reports, flows, and task editing — the abilities to run reports, run flows, and edit tasks are switched off on every REDA set, so the profile must grant them.
- Default app and tab visibility — both the REDA and REDA Admin apps ship; the profile decides which app opens by default and which tabs a user sees.
The practical guidance: keep profiles minimal — a clean baseline — and layer REDA's feature sets on top.
Why REDA uses permission sets, not profiles
REDA ships no custom profiles and no permission set groups. Every REDA capability arrives as an individual permission set you assign per persona. There is no pre-bundled "leasing role" profile to hand out, and no group that pre-combines several REDA sets into one. If you want a bundle, you build your own permission set group org-side — but never assume a profile already "includes" a REDA capability. It doesn't.
The role hierarchy
The role hierarchy is Salesforce's structure for management roll-up: it lets a manager see the records owned by the people below them. REDA ships no role hierarchy — you design it. In a REDA org, its main job is exactly that roll-up: letting an office manager see the deals, properties, and tickets owned by their team. The mechanics of building roles are Salesforce's; the reason you'd want one here is management visibility.
Sharing: org-wide defaults and sharing rules
Organization-wide defaults (OWDs) set the floor for who can see each object's records; sharing rules open access back up for specific groups. REDA ships none of these — no OWDs, no sharing rules, no sharing sets. Sharing design is entirely yours.
The REDA objects where sharing decisions actually bite are the owner-based, one-record-per-transaction objects — the deal or lease record (Opportunity), Property, Inquiry, Ticket, and their children (Invoices, Charges, Commissions). Those carry an owner, so who-can-see-whom is a real decision. REDA's reference and master data — Regions, Charge Codes, Rules — is typically visible to everyone and controlled by permission-set read access, not by sharing.
REDA prescribes no specific OWD. The pattern to follow: for owner-visible transactional records, decide between Private and Public Read/Write based on whether agents should see one another's deals; keep reference data open. The mechanics are in the Salesforce documentation below.
The division of labor
One table, so it's unambiguous what comes from REDA and what you build:
| Concern | REDA provides | You configure org-side |
|---|---|---|
| Feature access (leasing, billing, bookings…) | 31 permission sets (Admin / User / Read-Only pattern) | Assign per persona |
| Standard objects (Account, Contact, Task, Event) | — (nothing) | Profile or org-side permission set |
| Reports, flow run, task editing | — (switched off on all sets) | Profile or org-side permission set |
| Custom profiles | — (none packaged) | Build minimal baseline profiles |
| Permission set groups | — (none packaged) | Optional: build your own to bundle REDA sets |
| Role hierarchy | — (none packaged) | Design for management roll-up visibility |
| Org-wide defaults & sharing rules | — (none packaged) | Design for owner-visible REDA records |
| App / tab visibility | REDA + REDA Admin apps ship | Set the default app and tabs per profile |
Worked example: access for a six-person office
Meridian Properties runs a small office — one manager and three leasing agents, plus an accountant and an auditor. Designing their access touches all three layers:
If the office later prefers one-click bundles, they can wrap the REDA sets they use most into their own permission set group — REDA ships none, but nothing stops you building one.
Where to go next
- Creating Users & Granting REDA Access — create the user and assign the REDA sets.
- Understanding REDA Permission Sets — the 31-set model in full.
- The REDA Access Model — look up which set a given task needs.
- Securing Your REDA Org — lock down authentication and sessions.
- Editions: OEM vs ISV — which objects live on each edition.
Frequently asked questions
No. REDA delivers access through permission sets. Profiles carry the org-side baseline — standard objects, reports, flows, default app — which you build.
That's role-hierarchy roll-up and sharing — REDA ships neither. Design a role hierarchy for management visibility and sharing rules for the records that should be shared.
REDA requires no particular setting. Decide by whether agents should see one another's deals. The owner-based objects — deals, properties, tickets — are the ones worth thinking about; reference data is usually left open.
Yes — build your own permission set group org-side. REDA ships none, but nothing prevents you from combining its sets into a bundle you assign in one step.
The decisions are identical. On the ISV edition they apply to standard Lead, Opportunity, Case, and Campaign; on the OEM edition to REDA's custom Inquiry, Opportunity, Service Request, and Promotion. Same sharing thinking, different object names.
Was this article helpful?