Creating Users & Granting REDA Access

Onboarding a new team member in REDA is two moves, not one. First you create a Salesforce user — the login itself. Then you turn that bare login into a working leasing agent, accountant, or booking clerk by assigning the right REDA permission set. Creating the user is a standard Salesforce task, so this article keeps that part short and points you to Salesforce's own documentation. What it covers in full is the REDA-specific half: which license each edition needs, which permission set maps to which persona, and the two things REDA's sets deliberately do not grant — so you know exactly what to add yourself. No prior REDA experience is assumed.

The model: a Salesforce user plus REDA sets

A REDA user is a normal Salesforce user with one or more REDA permission sets layered on top. A permission set is a bundle of access — which objects, tabs, and actions a user can reach — that you grant to a user on top of their profile. REDA delivers all of its feature access this way: there are 31 REDA permission sets in the current release, and assigning them is what unlocks leasing, billing, bookings, inspections, and every other REDA capability.

Two things follow from that design, and both matter when you assign access:

• REDA ships no permission set groups — there is no pre-bundled "leasing role" you can assign in one click. You assign the individual sets a persona needs. Always think in terms of "assign these sets," never "this role includes."
• The sets follow a consistent naming pattern: REDA - [Domain] - Admin / User / Read Only. Create-and-edit access lives in the Admin and User sets; the Read Only twin lets someone view the same records without changing them.
• Sets add up. When a person holds more than one REDA set, their access is the sum of all of them — the widest grant wins on each record. That's why some personas below stack a couple of small, single-purpose sets (a front-desk coordinator, for instance, takes the booking set and the leasing set to also handle packages and visitors) rather than reaching for one broad set. Give each person exactly the sets their job needs, and nothing more.

Step 1 — Create the Salesforce user

From Setup → Users → New User, fill in the standard details — first and last name, email, username, and alias. A handful of fields on this screen matter especially for REDA:

Everything else on the New User screen is standard Salesforce. For the full walkthrough of the form, see the Salesforce documentation linked at the end of this article.

Step 2 — Pick the right license

REDA ships in two editions, and they run on different Salesforce license families:

• The Platform edition (OEM) uses REDA's own custom records — Inquiry, Opportunity, Service Request, and Promotion — so a Platform-family license is sufficient.
• The Sales Cloud edition (ISV) uses the standard CRM records — Lead, Opportunity, Case, and Campaign — so users need a license that includes those standard objects.

The principle to hold onto: OEM runs on Platform-family licenses; ISV runs on Sales-Cloud-family licenses. Pick the license that matches your edition and your purchased entitlement. The exact license name to select on the New User screen is a commercial detail tied to your agreement — confirm it against your license entitlement rather than guessing from the screen.

Step 3 — Assign the REDA permission set(s)

Once the user exists, open them from Setup → Users, go to Permission Set Assignments, click Edit Assignments, and move the sets the persona needs into the enabled column. Use the persona map below to pick the right ones.

One assignment carries special weight: the REDA Admin Console — the administrator's control tower for scheduling and configuration — is unlocked only by REDA - Master Data - Admin. A user without that set who opens the console sees:

Elsewhere in REDA, a user who lacks the set for a feature they try to reach sees the generic message:

The persona → permission-set map

Match the new user's job to a row, and assign the sets named in it. Where a persona spans several REDA domains (an accountant, for example), assign each set listed.

What you must also grant org-side

This is the part administrators most often miss. REDA's permission sets grant REDA's own features and nothing else — three kinds of access come from the profile or an org-side permission set only, never from a REDA set:

Deactivating and offboarding

Removing a departing user is a standard Salesforce task: freeze the user to cut off access immediately, then deactivate them to free the license. One REDA-specific caution: many REDA records — invoices, ownership trails, commissions — are owned or stamped by the person who created them. Reassign ownership of a departing user's active records before you deactivate them, per your data-retention policy, so ownership trails stay intact. REDA ships no dedicated reassignment tool; use standard Salesforce ownership transfer.

Worked example: onboarding Amara, a leasing agent

Amara joins Meridian Properties as a leasing agent on the Platform (OEM) edition. Here is the whole onboarding, end to end:

If Amara's manager only reviews deals rather than editing them, assign the manager the Read-Only twin where one exists rather than the doer set.

Where to go next

1. Understanding REDA Permission Sets — the full 31-set model, domain by domain.
2. The REDA Access Model — look up which set a given task needs.
3. Profiles, Roles & Sharing in a REDA Org — the org-side baseline and who-sees-whose-records.
4. Securing Your REDA Org — lock down logins and sessions at go-live.
5. The REDA Admin Console — the Master-Data-Admin-only control tower.

Frequently asked questions