Access and responsibilities
Permissions, tenant capabilities and record scope are separate checks. A button may disappear after an access change; the server checks authority again when an operation is submitted. A successful preview does not reserve permission to commit later.
Capability layers
| Work | Required capability context |
|---|---|
| Donor and fund foundation | CHARITY and its PARTY dependency |
| Donation workspace and draft commands | CHARITY, PARTY and ORGANIZATION |
| Financial posting, correction, reversal and financial queries | CHARITY_FINANCE and its CHARITY, PARTY, ORGANIZATION, PAYMENT and ACCOUNTING dependencies |
| Sponsorships and sponsor updates | CHARITY, CHARITY_SPONSORSHIP feature and CARE, with normal dependencies |
The sponsorship feature is off by default. Capability entitlement/configuration is maintained through Administration; installing a permission or creating a fund does not enable it.
Permission reference
Every code below is complete. Read access can be needed alongside command authority because the browser must load records, catalogues and configuration.
| Task | Main authority |
|---|---|
| Search donors / activate donor | charity.donor.view / charity.donor.activate |
| Search / create / update funds | charity.fund.view / charity.fund.create / charity.fund.update |
| Read / create / update / cancel donations | charity.donation.view / .create / .update / .cancel |
| Read lifecycle history | charity.donation.history.view |
| Read private notes, evidence and reasons | charity.donation.sensitive.view, plus ordinary record access |
| Read financial projections and previews | charity.finance.view, plus donation view and relevant action authority |
| Post / correct / reverse duplicate | charity.donation.post / .correct / .reverse, plus donation and finance view |
| Change the debit account within the same physical holding | Additional charity.donation.correct.cash-account |
| Configure settings, routes and mappings | charity.finance.configure, plus finance view |
| Advance business date | charity.finance.business-date.manage, plus finance view |
| Read inactive-unit financial history | Additional charity.finance.inactive-unit.view and a retained explicit unit grant |
| Correct/reverse in an inactive unit | Additional charity.finance.inactive-unit.correct and the relevant command rights |
| Financial CSV export | charity.finance.export, finance view and donation view |
| View/manage sponsorships | charity.sponsorship.view / charity.sponsorship.manage |
| Decide sponsor updates | care.sponsorship.update.approve |
| Sponsorship coverage report | care.report.view and charity.sponsorship.view, plus report execution scope |
In abbreviated cells, .create means the same prefix as the first full code, for example charity.donation.create. Party activation/search also needs the applicable Party access; financial configuration uses account lookups. Give staff the lookup permissions required by their approved task.
Unit access and specialist scope
Donation work needs explicit non-denied business-unit access. A primary unit is not a tenant-wide grant. Inactive-unit rights apply to posted/reversed history and permitted corrections; they never authorise a new post into an inactive unit.
Sponsorship alias access does not need a Care facility grant. It does not open the confidential Care record. Facility/programme lookup controls can still need their own Care permissions; Sponsorships explains browser limitations.
Example: Nadia may preview and post at North with the right grants. payment.post alone cannot post a Charity donation. Omar may view Willow-27's sponsor alias without seeing the person's real name, origin or health details.
Use Administration for role assignments and capability setup. Test the intended action and one disallowed action after a fresh sign-in rather than assigning a broad administrator role to solve a missing button.