Suite Implementation Sequence

Setup walkthrough 9 min read Updated July 2026

The full REDA suite is layered on purpose: a property-management core, an accounting layer on top, customer messaging, a public listing site, and three extensions that bridge them all — and each layer depends on the ones beneath it. This partner-facing guide gives you the order of operations the reference implementation follows: install seven packages in sequence, deploy the integration glue, seed the financial master data, work through the manual configuration, and create users under a profile-first access model. Follow it top to bottom and the dependencies line up; install out of order and pieces won't find what they expect.

Getting there. This is a sequence and checklist rather than a single screen. Each surface it references — listings, applications, the resident portal — has its own article linked at the point it's needed.
Access you'll need. Carrying out an implementation requires org-administrator access. The end-state access your users receive is the profile-first model described in the final step.

The suite at a glance

Seven packages make up the verified installation, each contributing one capability:

Package	What it contributes
REDA Platform	The property-management core — properties, leases, tenants, tickets
REDA Financials	Full accounting
REDA Connect	Customer messaging over WhatsApp and SMS
REDA Digital Experience — Listing	The public website listing of available properties
REDA Financials Extension	The bridge between the property core and accounting
Lease Applications Extension	The online lease-application form
Resident Portal Extension	The resident portal

Step 1 — Install the packages in order

Install the seven in the sequence below. The order is a dependency order: the extensions add fields and behavior onto the core and accounting packages, so the base layers must exist first.

#	Package	Verified version
1	REDA Platform	Monsoon 2026 (1.44.0)
2	REDA Financials	Monsoon 2026 (1.5.0)
3	REDA Connect	Monsoon 2026 (1.92.0)
4	REDA Digital Experience — Listing	Spring 2025 (1.5.0)
5	REDA Financials Extension	Monsoon 2026 (1.1.0)
6	Lease Applications Extension	Monsoon 2026 (1.0.0)
7	Resident Portal Extension	Monsoon 2026 (1.1.0)

Seven packages, not eight. Older runbooks mention a separate content-and-image package. It is not part of the verified installation, and its image-pipeline role is inoperative — listing images use the property's own image-URL field instead. Install only the seven above.

Step 2 — Deploy the integration glue

On top of the packages sits a layer of configuration that wires everything together — the record pages, permission sets, profiles, roles, apps, tabs, and the automation that moves data between the property core and accounting. Deploying it is a single co-ordinated step after the packages are in.

For scale and confidence, the reference implementation's glue layer includes 7 business permission sets, 56 profiles (of which 26 are REDA business profiles), 31 roles, and a set of consolidated record pages — the raw material the access model in Step 5 draws on.

Step 3 — Seed the financial master data

Accounting needs a starting chart of accounts and a set of charge codes wired to it. A repeatable seed brings up:

Six property-management income accounts — from Rental Income (4210) through Utility Recovery (4260), plus a Customer Deposits account (2210).

Seven products, each linked to its default revenue account.

Sample charge codes linked to those products, so billed charges know where to post (see Charge Code Accounting Setup).

The full accounting chart and sample charge codes ship inside the accounting package; the seed adds the property-management specifics on top.

Step 4 — Manual configuration

A handful of steps can only be done by hand after the automated pieces are in place:

Activate the accounting license. The license key is the gate that lets accounting post — nothing books until it's active.

Activate the record pages as org defaults. Set the 25 supplied record pages as the org's defaults so users see the consolidated layouts.

Confirm the org settings — multi-currency and activities — and the email and calendar integration.

Set the integration keys. Confirm the accounting bridge is switched on, and set the base web addresses for the lease-application form and the resident-ledger site.

Configure the listing site — its map key, public addresses and thank-you pages (see Publishing Properties to Your Website), rotating the map key to your own.

Sites at go-live. A complete reference implementation ends with two live community networks — Residents and REDA Services — and six active sites, including the public listings site, the service site that hosts the application form, and the resident-ledger site.

Step 5 — Create users: the profile-first model

This is the step that most often surprises teams coming from a permission-set-heavy background. The suite does not ask you to assemble permission sets per user. Instead, the capability of every packaged permission set has been pre-folded into around 26 ready-to-use profiles — REDA System Administrator, Financial Controller, Accountant, Property Manager, Leasing Consultant, Sales Agent, Front Desk Agent, Maintenance Technician, Owner Services, and more — sitting over a 31-role hierarchy that mirrors a property firm's org chart.

Assign Profile + Role, and stop. Creating a user is a two-part decision: pick the profile that matches their job and the role that matches their place in the org chart. There is no per-user permission-set assembly by design — the profiles already carry it.

You'll still see the underlying permission sets named in the core product's own help articles. That's expected, and it's worth explaining to a team that's new to the model so nobody goes hunting for sets to assign: those sets remain the vocabulary for describing what a profile can do — the suite implementation simply pre-packages them into profiles so you don't hand-assign them one user at a time. When an article says a capability needs a particular permission set, read that as "the profile that carries this capability includes that set." The set describes the capability; the profile delivers it.

Verification checklist

Prove the wiring before you hand the org over:

The accounting bridge is on. Confirm the integration gate is switched on and the license key is active.

The sites resolve. Open the listings site, the service site and the ledger site at their configured addresses.

The bridge round-trips. Create an invoice and confirm its accounting counterpart appears with the link stamped — the proof the two sides are joined.

Nothing bills on a schedule until you schedule it. The recurring billing jobs are not pre-scheduled — that's a required admin step, not something the install does for you. A fresh org runs only two schedules on its own — a payment-schedule posting run and a calendar-slot top-up — and neither bills anyone. Schedule the rest before go-live or the first invoices appear and no further rent is billed (see Scheduling Background Jobs).

Test the layers that go quiet. Payments, management fees, owner draws and bank file processing are ready but easy to leave unexercised. Put each on the go-live test plan so the first real transaction isn't the first test.

Worked example: a five-day Meridian go-live

Day	What happens
Day 1	Install packages 1–7 in order
Day 2	Deploy the integration glue; run the master-data seed
Day 3	Activate the license and record pages; configure sites and branding; set the integration keys and listing config; confirm the accounting gate
Day 4	Create users — Financial Controller for the controller, Leasing Consultant for agents — each with a role per the org chart
Day 5	Smoke tests — publish a unit, submit a web inquiry, send a lease application, create an invoice and confirm its accounting link

Where to go next

How REDA Works with REDA Financials — the accounting bridge you smoke-test in Step 5.
Publishing Properties to Your Website — the listing site configured in Step 4.
Online Lease Applications — the application form the service site hosts.
The Resident Portal — the resident community site and its setup.
Scheduling Background Jobs — the billing jobs nothing schedules for you.
Charge Code Accounting Setup — the charge codes the seed links to products.

Frequently asked questions

The implementation folds the packaged permission sets into ready-to-use profiles. Assigning a user is just Profile + Role — the profile already carries the capabilities the sets describe.

It isn't part of the verified seven-package installation. Listing images use the property's own image-URL field (see Publishing Properties to Your Website).

The recurring billing jobs aren't pre-scheduled. Scheduling them is a required admin step (see Scheduling Background Jobs) — until you do, the first invoices appear but no further rent is billed.

The 31-role hierarchy mirrors a property firm's structure and pairs with the profiles, so most implementations use it as delivered. Choose the profile for the job and the role for the reporting line.

Was this article helpful?