Permissions are set per capability across 30+ areas of the product: transactions, bills, reimbursements, vendors, reports, settings, and more. Build roles that match real jobs, like bookkeeper, field manager, or approver.
In multi-entity setups, a role can apply to one subsidiary and not another. Your property accountant sees their portfolio, not the whole company.
New team members start as members, not admins. Elevate access deliberately, and change it any time without touching the person's history.
Finance software tends to offer two roles: admin and everyone else. Real companies need more shades than that. The bookkeeper needs everything except settings. The field manager needs their team's expenses and nothing else. The owner wants read access to all of it and edit access to none of it.
Clyr's permission system is granular across 30+ areas of the product: transactions, bills, reimbursements, vendors, reports, settings, and more. Build custom roles that match real jobs instead of bending real jobs to fit two roles.
In multi-entity setups, a role can apply to one subsidiary and not another. Your property accountant sees their portfolio, your regional manager sees their region, and leadership sees everything. Access follows the org chart instead of fighting it.
New team members start as members, not admins. Elevation is a deliberate act, and changing someone's role never touches the history of what they did. When people leave, removing access is one change, not an archaeology project.
Yes. Roles are built from granular permissions across 30+ product areas, so you can model bookkeeper, approver, field manager, or read-only owner exactly.
Yes. Roles are scoped per entity in multi-entity setups, so access maps to the org chart.
Remove their access in one change. Their historical activity stays on the record for audit purposes.