The brief this episode is generated from. It is the input to the recording tool, not a transcript of what the hosts said — and it is the only brief. The outline goes in beside it as the second Source; a second brief would not correct this one, it would argue with it.
The Industry’s Names for the Job
Source brief for a short two-host deep dive. Audience: PropFlow’s founders and team, and anyone who understands how a property management company is staffed but has never looked at how software decides who may do what. Everything below describes the product as it is on September 10, 2026, what the market calls these jobs, and a proposal on top of it. When the brief says “we should”, that is a recommendation awaiting a founder’s decision, not a change already made. Outside systems are named by their role where the name does not matter, and by name where the name is the point.
A word that is read in eight places
PropFlow is the software a property management company uses to let Clara, its AI coworker, answer calls, texts and emails for their buildings. When the company’s people sign in, each of them holds one role: a single word stored on their membership in the company.
The natural assumption is that this word just decides which menu items appear. It does that. But an audit of the live code on September 10 found the same word read in eight distinct places, and only the first is about the screen.
The sidebar and pages hide what a person cannot use. The front door checks the role against the web address of every page before it loads. The back door checks it again on every save, edit and delete. The invite rules use it as a ladder: you may only invite someone at your own level or below. The building list uses it: company admins see every building, everyone else sees an assigned list.
Then there are three places that reach into Clara herself. When someone calls or texts the property’s line, Clara checks whether that number or address belongs to a person holding a staff role in that company; if so she switches to her staff voice and stops treating the caller as a prospective tenant. Her tools, the actions she can take during a conversation, are gated per role: a view-only person can only ever trigger read tools. And when a renewal is coming or a call was missed, the people who get paged are chosen by role.
The eighth place is the first sign-in. Only a company admin is walked through the setup wizard and asked to accept the terms.
So a role is a small word with a long reach, and that is why the list needs to be short and stable before real customers arrive.
Two things a role deliberately does not control. First, what the company has paid for: a company’s modules are the outer gate, and a role can only narrow inside it. Second, whose property management system login is on file for a building. That is a technical field on the building record which, in the code, happens to be called “owner”, and Gera’s portfolio design flags it as something that must never appear in a roles list.
Ten names, five behaviours
The product currently defines ten staff roles. Platform Admin is PropFlow’s own staff. Organization Admin is the top of a customer’s own team, and the only role that can hand admin rights to someone else. Property Manager has full day-to-day access to their assigned buildings. Leasing Agent has full leasing access and reads the rest. Maintenance is the mirror image. Viewer reads everything and changes nothing.
That is six. The other four were added on August 19: Regional Manager, Accounting, Assistant Property Manager and Leasing Assistant. They were added so a teammate’s real job title could be shown, with a sensible ruling that relabelling must never quietly take a feature away. The engineers honoured that literally: all four point at the Property Manager’s permission table, by reference. Choosing “Accounting” instead of “Property Manager” changes the word on a badge and nothing else. The one sliver of difference is that Regional Manager sits half a notch higher on the invite ladder.
Ten names, five behaviours. The audit confirmed this by reading the permission tables, not by inference.
Three screens, three lists, and one dead one
A role can be picked in three places, each written separately. The onboarding wizard’s “add your team” step offers five. The Settings page, where a customer’s own admin manages their team, offers seven to ten depending on who is inviting, because it computes the list live from the invite ladder; it is the only screen that cannot drift. The back office, where PropFlow staff invite someone into a customer, offers three.
And a fourth screen exists in the code that offers all ten and posts to an older invite path. Nothing links to it. Dead invite code is a hazard rather than clutter, because the day someone wires it back in, the old list and the old path return with it.
Nine people, three roles, twelve with none
The production user table was read on September 10, counts only. Twenty-one users. Five are PropFlow staff. Three are property managers. One is a viewer. Twelve have no role stored at all. Every other role, including Organization Admin and all four title roles, has zero users.
Twelve of twenty-one with no role is more than half. It is almost certainly a missed backfill from an earlier migration, and it is the same shape of problem that bit on September 10, when a silent failure in the role lookup turned a real company admin into a viewer for one request with no log and no alert. That was fixed the same day. The empty rows were not.
And not one customer admin exists yet. Every real customer who signs in next week, at Western Slope, at Situs Group, at ConAm, will be the first real person to walk that path.
How six became ten
On March 17 the first roles system shipped for the pilot with seven roles. On May 10 the company model was designed, the design Fede half-remembers as “a really old ADR”: it split the catch-all admin into PropFlow staff and a customer’s own admin and collapsed the extras. Six roles, each distinct. That May design was already the simple one. On August 19 the four title roles were added, because “show the right job title” was solved by adding a role per title. A title is not a permission, and that conflation is the whole story.
The founder’s rule: name the job, in the industry’s words
The first draft of this proposal reached for an abstraction: five “seats” with generic names like Manager and Leasing. Fede rejected it, and the reason is worth keeping. A role should map to the job a person holds in their company, because that is a known and established pattern, and “manager” is too generic while “leasing” is not a job title at all. Two more rulings landed the same evening: no accounting role for now, and start with the minimum set, add later.
So the question changed from “what abstraction is cleanest” to “what do the people at Western Slope, ConAm and Situs already call each other, and what do the systems they use call these jobs”.
What AppFolio calls them
All three customers run on AppFolio, so its vocabulary is the most binding. AppFolio ships thirteen standard user roles, each customisable per company, and its higher tier lets a company copy a role under a new name. The list: President, who can do everything including manage users and see sensitive personal data. Accountant. Property Manager, with full edit on properties, tenants, vendors and owners and limited accounting. Assistant Property Manager, which is Property Manager minus the ability to delete. Regional Manager, which AppFolio describes as starting with Property Manager’s permissions and meant to be widened for people with more authority. On-Site Manager. Leasing Agent and Assistant Leasing Agent. Accounts Payable and Accounts Receivable. View Only. Maintenance Coordinator, who runs all maintenance and vendors. Maintenance Technician, who sees only their own work orders in a mobile view.
One more thing AppFolio is clear about: owners are not users. An owner gets a separate Owner Portal with its own per-owner permissions for the dashboard, reports and documents. Buildium, RealPage and Yardi have the same shape. Nobody in the market hands a landlord a staff role.
What the rest of the market calls them
Institutional multifamily, the world of RealPage, Entrata and the National Apartment Association’s credentials, says Community Manager for the person who runs one building, Leasing Consultant for the person who leases, Regional Manager or Regional Property Manager for the person over several buildings, and Maintenance Supervisor and Maintenance Technician for the people who fix things. Each has a credential: CAM for the community manager, CALP for leasing, CAPS for the regional, CAMT for maintenance.
Third-party and smaller operators, the world of AppFolio, Buildium and Yardi Breeze, say Property Manager and Leasing Agent for the same two jobs. Yardi’s big system, Entrata and Rent Manager ship configurable security groups rather than fixed names; their customers configure the same job names.
The AI leasing tools are thinner. EliseAI documents Organization Admin, Community Admin, Owner, Delinquency Agent and Analyst. Funnel documents Admin and User. The rest publish nothing.
What our own customers call their people
At Western Slope, Jason Fish is managing broker and partner, Jay Taylor is partner, and Jay asked today whether both could be admins. Kat Barker is the leasing manager, and Beverly, her virtual assistant, is called “Assistant PM” in their own system. At ConAm, Dara Johnson is the regional portfolio manager, the person Sean expects to be the global admin for that organization, and Jaise Sylva is the community manager at Yale 25 Station. At JP&Co, Kenya is the regional manager. On the ownership side, Sean’s father, or Sean acting for the owners, wants to watch a building without touching it.
Six roles
Put the four sources together and the minimum set writes itself. Organization Admin, which AppFolio calls President and EliseAI calls Organization Admin: the bosses, one or two per company, who run settings, billing, integrations and the whole team. Regional Manager, the same word in AppFolio, RealPage, Entrata and the NAA: oversees the on-site teams across buildings. Property Manager, AppFolio’s word and two of our three customers’ word, with Community Manager as the hint for institutional shops: runs a building day to day and gets paged. Leasing Agent, again AppFolio’s word, with Leasing Consultant as the institutional synonym. Maintenance Technician, AppFolio’s word and the NAA’s credential, one role covering coordinators and technicians until a customer needs the split. And Owner: read-only, scoped to the buildings they own, never paged.
Plus PropFlow staff, which is not a customer role and is never offered to one.
Which buildings a person covers stays a separate setting on their membership, because Kat covers every Western Slope building and Jaise covers one, and the same word has to describe both.
Against today’s code the change is small. Organization Admin, Property Manager and Leasing Agent are untouched. Maintenance becomes Maintenance Technician in name only. Viewer becomes Owner in name, plus reach limited to what they own; Gera’s ownership record replaces that manual scoping later and nothing has to be undone. Accounting, Assistant Property Manager and Leasing Assistant stop being offered; the values stay valid in the database and nobody is renamed, and since nobody uses them there is nothing to migrate. Assistant Property Manager is the most likely first addition, because AppFolio has it and Western Slope already uses the title.
The one real change is Regional Manager. Today it is a label equal to Property Manager. The proposal makes it what AppFolio describes: Property Manager’s permissions across every building in the company, plus inviting and managing the on-site staff, with no billing and no company settings. That is where Kenya sits, and it is one of the decisions.
One place for roles, and nobody gets their own copy
Fede asked the structural question too: how do we consolidate roles into one place and make sure nobody adds their own list again. The answer has two halves.
The first is being built tonight as a dark change with no visible difference. A single role catalog, one file, holds every role’s name, label, one-line description and the screens allowed to offer it. The wizard, the Settings page and the back office stop carrying their own hand-written lists and instead ask the catalog which roles they may offer to this inviter. Beside it sits a guard test in the build, the same shape as the existing fence against customer identifiers in code: it walks the source and fails the build if any other file writes its own list of roles. It is a ratchet, so a new copy fails even in a file that was allowed before.
The second half waits for the decisions and ships as small separate changes: flip the catalog to the six roles, relabel Maintenance and Viewer, make Regional Manager real, delete the dead invite screen, backfill the twelve users with no role and refuse to save a membership without one.
What is left alone
How Clara recognises staff and which tools each role may trigger are already keyed on the same behaviours. Who gets paged stays as it is. Company modules stay the outer gate. The company admin’s first sign-in, terms and second factor and setup wizard, is unchanged.
Three decisions
The page carries three decisions for Fede, each with a recommendation. The starting set: six, as above, or six plus Assistant Property Manager, or five with regional managers folded into Organization Admin. What Regional Manager means: a real company-wide role with team management, or the alias it is today. And Owner: rename Viewer to Owner now with reach limited to their buildings, or wait for the ownership record.
Three things were ruled today and are not re-asked: roles are named for the job a person holds in their company, there is no accounting role for now, and the set starts minimal and grows only when a customer asks.
The reason to decide this week is the one Fede gave: once customers are onboarded this gets much harder to undo, and today the whole system is nine people holding three roles. That is the cheapest it will ever be to make it simple.