Collaboration
Invoice Crowd combines reusable roles, per-area permissions, business-profile assignments and optional customer restrictions so an invited teammate can work in the right context without inheriting every owner capability.
Last updated:
How it works
Access is assembled from identity, owner relationship, selected businesses and permissions rather than a single broad team switch.
A pending invitation is tied to an email address and expires rather than granting immediate access.
Owners create a pending team relationship and send a time-limited join link. Acceptance must match the invited email before the relationship becomes active.
The add-member control checks the available member allowance, including configured add-ons, before a new invitation can be created.
Reusable roles translate business responsibility into module and action permissions.
Owners can build roles across product areas and action flags such as full access, create, edit, delete, export, share and schedule where those actions apply.
Team authorization resolves the requested module and capability. Unknown modules are denied instead of being treated as implicitly allowed.
A role answers what; assignments answer which business and customer records.
An invitation can include one or more business profiles. The active business remains part of the record scope during day-to-day work.
Owners can allow all customers in the assigned context or constrain the member to a selected customer set when the workflow requires narrower access.
Capability map
The practical controls owners and invited members encounter, including plan limits and owner-only areas.
Invite by name and email through a pending, time-limited relationship.
Create owner-defined roles that can be applied to multiple members.
Control visible product areas instead of granting one universal team role.
Preserve create, edit, delete, export, share and schedule decisions where supported.
Named checks protect actions that need more than ordinary module visibility.
Choose which business profiles a member may work within.
Allow all customers or select a narrower customer set.
Billing, settings and the owner profile remain owner-only surfaces.
Available team seats follow the current subscription and member add-ons.
A still-pending invitation can be sent again without activating it.
Deleting the team relationship removes access instead of deleting business data.
System or assigned roles have ownership and deletion guards.
Questions
Yes. A team invitation can be assigned to selected business profiles, and the active business remains part of the application scope while the member works.
Yes. The team relationship can allow all customers or carry a selected customer list for a narrower working set.
No. It creates a pending relationship and a time-limited invitation link. The accepting account email must match the invited email before activation.
No. Billing, settings and the owner user-profile surface are owner-only in the current root application authorization contract.
The current authorization contract denies unknown team modules by default rather than treating the absence of a rule as permission.
No. Role deletion is blocked while a team relationship is using that role, which prevents an assignment from silently losing its meaning.
Start with one role and one representative business assignment, verify the member view, then expand access only when the workflow needs it.
