Roles and member rates

The question this page answers

People new to Syndik8 often ask “how do I make someone a renter?” There is no renter role to assign. The answer is that you assign the member to a rate called “Renter” (or whatever name the syndicate has chosen for its non-equity billing scheme). The member’s role stays as member. This page explains why the design works that way.

Role governs what you can do. Rate governs what you pay.

Every member of a syndicate has exactly one role and is assigned to exactly one member rate. The two are independent:

Role — owner, admin, member, or viewer — controls what the member can do. It decides whether they can invite others, finalise bookings, edit the asset, see other members’ financial detail, book at all, and so on. See the role capability matrix for the full breakdown.
Member rate — the billing scheme assigned to the member — controls what the member pays. It decides the dues amount, the dues interval, and the hourly rate modifier applied to the asset’s base rate. See member rates.

Changing a member’s role has no effect on their rate. Changing their rate has no effect on their role. They are two orthogonal dimensions.

The 2 × 2

Any combination is valid. Four illustrative cases:

Role	Rate	When this happens
`member`	Equity member	The common case: a partner who bought in, pays monthly dues, flies at the base rate.
`member`	Renter	A non-equity participant on a higher hourly with a token annual fee. Still a `member` — books, logs usage, sees the calendar, like any other.
`admin`	Equity member	Typical: the treasurer or a co-owner with admin privileges, paying the equity rate because they are an equity partner.
`admin`	Renter	Rare but valid: an admin who, for whatever historical reason, pays the renter rate. Their admin powers are unchanged; their hourly charge is still driven by their rate.

Nothing in the system prevents the rare combinations. The finance layer reads the rate; the permissions layer reads the role. Neither looks at the other.

Why not make renter its own role?

It would be a tempting shortcut — one dropdown instead of two. The design resists it for three reasons:

The set of rates in a syndicate is open-ended. A syndicate might run equity, renter, instructor, and founder schemes side by side, each with different dues and modifiers. If rate were a role, every syndicate would want custom roles, and the system would drift towards a per-syndicate permission editor — large surface area, high risk.
Roles map to capabilities, not prices. The existing four roles (owner, admin, member, viewer) are the right granularity for capability. A “renter” role would have the same capabilities as member with none added or removed; it would be a label masquerading as a permission level.
Billing flexibility would collapse back onto the role. If renter were a role, “change someone from renter to equity” would be a role change — i.e. a permissions change. That would conflate two separate operations an admin genuinely needs to do independently: reassigning a member’s financial terms (common, often reversible) versus adjusting their capabilities (less common, a different review).

Keeping them separate means the member role stays small and well-understood, and the billing scheme layer can evolve freely. A syndicate that invents a fifth scheme tomorrow doesn’t need a new role.

What this means for how you talk about your syndicate

Language drifts when two concepts are orthogonal. A few habits the docs follow, and which are worth adopting in conversation within your syndicate:

“Renters” is not a group of people. Write “members on the renter rate”.
“Our admins” is a role statement; “our equity members” is a rate statement. They are not the same list.
When you promote someone to admin, you are not changing what they pay. When you move someone from the equity rate to the renter rate, you are not changing what they can do.

In the app, role is set on the Edit member dialog; rate is set on the member’s detail row under Members. The two controls live in the same screen but have nothing to do with each other.