Not for Profit
Connect the people, funding
and services behind the mission.
MissionVisibility
For charities, membership organisations and other mission-led organisations where people, funding, services and evidence need to stay connected. Not for Profit is not one operating model, so we start with the kind of organisation this is before discussing any platform.
The organisation may be mission-led. The operating model still needs clear information, accountability and financial control.
In short
What a Not for Profit decision actually depends on.
These are the questions leadership has to answer before a platform question means anything. They are areas to establish, not promises.
Not one operating model
Some organisations deliver services, some serve members, some raise funds, some distribute funds and some work under commissioned contracts. Many combine several.
People and relationships
Beneficiaries, members, supporters, funders, partners and volunteers are different relationships with different access requirements.
How funding enters
Grants, donations, subscriptions, contracts and other income behave differently and should not be treated as one thing.
How value is delivered
Service, membership activity or grant distribution, coordinated across teams, volunteers and partner organisations.
Finance and control
Budgets, restriction, programme position, purchasing, cash and audit remain a financial-control requirement whatever the mission.
Evidence for leadership
Trustees, funders and commissioners need evidence drawn from the operating process rather than reconstructed at month end.
Sensitive information
Purpose, minimum data, access, retention, sharing and audit decide the design before any feature does.
The route that fits
Assessment, Transform, implementation, RAPID qualification, Recover, Optimise, Support or Partner Transition, chosen from the situation rather than the sector.
Operating model
Not for Profit is not one operating model.
Some organisations deliver services, some serve members, some raise funds, some distribute funds and some work under commissioned contracts. No organisation needs every archetype, and many combine several.
Service-delivery organisation
Beneficiaries, referrals, cases, programmes and outcomes coordinated across teams, volunteers and partners.
- Referral
- Assessment
- Case
- Programme
- Outcome
Membership organisation
Members, subscriptions, engagement, events, benefits and renewal held as one connected relationship.
- Member
- Subscription
- Engagement
- Benefit
- Renewal
Fundraising-led charity
Supporters, campaigns, donations, stewardship and the allocation of funds to purpose.
- Supporter
- Campaign
- Donation
- Stewardship
- Allocation
Grant-funded or grant-making organisation
Funders, applications and awards, conditions, programmes, evidence and reporting in both directions.
- Award
- Condition
- Programme
- Evidence
- Report
Commissioned service provider
Service agreement, delivery, evidence, financial position and commissioner reporting.
- Agreement
- Delivery
- Evidence
- Position
- Reporting
Mixed model
More than one of the above running at the same time, often with different systems behind each.
- Multiple income
- Multiple audiences
- Shared administration
Where the model is unclear, or does not match any of these, that is a reasonable starting point for a conversation rather than a problem to resolve on a web page.
The operating reality
The mission may be simple to explain. Delivering it is rarely simple.
A single service can depend on need, referral, eligibility, assessment, funding, a partner organisation, a volunteer, a case worker, a grant condition, evidence and a reporting deadline.
Someone needs a service
The referral arrives with partial information, and the work begins before anyone has the full picture.
The organisation has to understand the need
Assessment, eligibility, evidence and priority all depend on information held in different places.
A service, person, partner or programme responds
Internal teams, volunteers and partner organisations may all be involved in the same case.
The activity consumes people, time and funding
Service activity consumes capacity and may need to be understood against the funding or programme supporting it.
The organisation needs to know what happened
Actions, decisions and evidence should stay connected to the person and the programme.
Funders and trustees need evidence
That evidence should come from the operating process, not from a month-end reconstruction.
When these are disconnected
- Staff chase information
- Funders receive delayed reporting
- Service data becomes inconsistent
- Beneficiary history is fragmented
- Financial reporting becomes harder
- Activity and outcomes are hard to connect
Administration should support the mission. It should not become the mission.
Technology cannot remove the complexity of service delivery. It can reduce the effort required to coordinate information, ownership and reporting around it.
Service-delivery archetype
Connect need, service, funding and outcome.
Eight stages, running across five threads. Service-delivery organisations may coordinate these stages across several teams and systems. This is one archetype rather than the universal Not for Profit operating model.
- Beneficiary
- Funding
- Partner
- Service
- Data
Engage
Enquiries, referrals and first contact captured consistently rather than across inboxes.
Understand
Need, context, history and any existing relationship with the organisation.
Assess
Eligibility, evidence, risk, priority and service fit, decided by the appropriate people.
Coordinate
Owner, internal team, volunteers and partner organisations identified and briefed.
Deliver
Appointments, interventions, actions, communication and documents in one case record.
Monitor
Progress, waiting work, overdue actions and cases needing attention.
Report
Service activity, spend, grant conditions and outcomes drawn from structured work.
Learn
What demand is changing, what is working and where capacity is constrained.
Membership archetype
A membership is a relationship with a renewal date attached.
Relevant where the organisation is a membership body. Not every charity is a membership organisation, and the model should not assume it.
Prospect
Interest, enquiry or eligibility question captured before it becomes an email thread.
Join or apply
Application, eligibility where relevant, membership type and first payment.
Member
Status, category, organisation or contact relationship and communication preferences.
Subscription
Term, price, payment method, arrears position and reconciliation with Finance.
Engagement
Communication, participation, interests and activity that indicate a live relationship.
Benefit, event or service
Entitlements, event attendance and member services delivered against the membership.
Renew
Renewal window, reminders, payment and any change of category.
Lapse or reactivate
A lapsed member is a different relationship state, not a deleted record.
Areas that usually need structure
- Membership type
- Status
- Renewal
- Payment
- Communication
- Event and activity
- Benefits
- Engagement
- Organisation and contact relationship
Our published membership evidence is a customer video with the British Society of Lifestyle Medicine, which demonstrates Dynamics 365 delivery with a membership organisation.
Supporters and fundraising
The relationship and the transaction are different records.
Where fundraising forms part of the model, these are the questions the design has to answer. We do not claim specialist fundraising functionality unless it has actually been implemented.
- Who supports the organisation?
- What campaign or appeal created the relationship?
- What donation or commitment was made?
- Is giving one-off or recurring?
- What communication preferences apply?
- What acknowledgement or stewardship is required?
- What purpose or programme is the funding intended to support?
- How does the transaction reconcile with Finance?
- Which fundraising or payment platform remains authoritative?
Donation and payment architecture
- 01Website, fundraising platform or payment service
- 02Supporter relationship
- 03Donation or payment event
- 04Finance
- 05Programme or purpose where relevant
- 06Reporting
The CRM does not need to become the payment platform. It needs the information required to manage the relationship and reconcile the financial event responsibly. Microsoft business applications do not replace specialist payment processing.
Where Gift Aid forms part of the fundraising model, declaration, eligibility and finance processes need a controlled design aligned to the organisation's approved tax process.
Funding models
Funding should remain connected to the activity it exists to support.
Not all income is a grant. Grant, supporter, membership, commissioned and trading income behave differently and need different structures behind them.
Grant funding
- Funder
- Award
- Restriction
- Programme
- Evidence
- Report
Supporter funding
- Supporter
- Donation
- Purpose
- Stewardship
- Finance
Membership income
- Member
- Subscription
- Entitlement
- Renewal
Commissioned or contracted service
- Commissioner
- Agreement
- Delivery
- Evidence
- Billing and payment
Trading and other income
- Activity
- Income
- Finance
We design against your accounting model. We do not give accounting advice, and we do not claim specialist charity-accounting capability.
Outcomes and impact
Activity is easier to count than impact.
Separating activity, output and outcome is what keeps reporting honest. The organisation defines the outcome framework.
- 01
Need
What the person, member or community requires, described consistently.
- 02
Activity
What the organisation actually did, captured during the work.
- 03
Output
The countable result of that activity.
- 04
Outcome
The change the organisation set out to create, defined by the organisation.
- 05
Evidence
The record that supports the claim, gathered as part of delivery.
- 06
Review
Whether the evidence supports the outcome, and what should change.
The system can connect activity to the organisation's defined outcome framework. It cannot prove impact simply because two records are related. We connect activity to outcomes where you have a meaningful way to define them. We do not invent outcome frameworks.
Value realisation
Measure the operating outcome, not the feature count.
Technology value should be measured in the operating outcome it improves, not in the number of features deployed.
Mission or business outcome
The operating result leadership wants to move, expressed in the organisation's own terms.
Baseline
The current position measured before change, so improvement can be recognised later.
Operating change
The change in process, ownership or information that creates the result.
Platform capability
The configuration, integration or automation that supports the operating change.
Adoption
The teams, volunteers and partners actually working the new way.
Evidence
The measure re-taken against the same baseline definition.
Review
Whether the outcome moved, and what the next justified step is.
Areas worth baselining first
- Referral administration
- Waiting work
- Case ownership
- Funder reporting effort
- Membership renewal administration
- Supporter-data quality
- Volunteer coordination
- Manual reconciliation
We do not publish improvement percentages. The baseline is yours, taken before the change and re-taken against the same definition afterwards.
People and services
Keep the relevant context around the person receiving support.
Beneficiaries, referrals, assessment, cases, volunteers and knowledge. Not every organisation needs all of these, and access should always stay role appropriate.
- Identity, contact, household or organisation relationships, referral and need
- Service, case, history, documents, partner activity, access and outcome
- Access should stay role appropriate. We do not claim a complete single view of all personal information
- Keep the relevant context around the person, not everything about them in front of everyone.
Safeguarding boundary
The platform can support recording, routing, escalation and audit. It does not define the organisation's safeguarding policy or determine safeguarding compliance. Safeguarding decisions stay with the people accountable for them and are not automated.
Illustrative example
A person is referred to a community-support service.
An illustration of how the process holds together, not a description of a specific customer or individual.
Refer
A person is referred to a community-support service and the referral is captured consistently.
Assess
Need and service fit are reviewed by the appropriate people.
Coordinate
The relevant internal team and partner organisations are identified.
Support
The service or intervention is delivered and recorded as it happens.
Record
Actions, documents and evidence stay connected to the case.
Review
Progress and outcome are reviewed at an agreed point.
Report
Operational and funding information can be understood from the structured process.
Partner working
Partner working is an information-sharing design problem before it is a portal decision.
Councils, healthcare, community organisations, advice services, housing and education may all be involved in the same case. We do not assume every partner receives direct CRM access.
No direct system access
Controlled communication and document exchange, with the record of the interaction still held internally.
Form or portal
External structured interaction where the volume, consistency or turnaround genuinely justifies it.
Direct application access
Only where identity, security, licensing and operating need justify it, with role-based restriction designed first.
System-to-system integration
Where a partner already operates its own platform and the exchange is defined, monitored and owned.
Security and information sharing
Sensitive information needs clear ownership and role-based access.
Roles, teams, restricted records, consent where appropriate, auditability and sharing with external partners are design decisions, not settings applied at the end.
Purpose
What information is needed and why?
Minimum data
What does the role actually need to see?
Access
Which staff, team, volunteer or partner role?
Retention
How long does the organisation need the information?
Sharing
What can be shared externally, with whom and under what agreement?
Audit
Which important access or decisions require traceability?
A connected record should not become an unrestricted record.
Volunteer access should not be treated as identical to employee access, and partner access should be modelled around what information is needed, by whom and for what purpose. We design against your information-sharing model rather than making blanket compliance claims.
Explore Security & GovernanceArchitecture
Service information and financial information should connect without becoming the same thing.
One operating model does not require one application. It requires clear ownership of each important fact.
Experience and entry
- Website
- Forms
- Portals
- Fundraising platforms
- Events
- Partner channels
Relationship and service
- CRM
- Dataverse
- Power Platform
- Case and service capability
Finance
- Business Central or appropriate ERP
- Budget
- Purchasing
- Cash
- Projects
- Finance reporting
Data and intelligence
- Power BI
- Fabric where justified
- Data & AI
CRM and Power Platform
- People and relationships
- Referrals
- Cases and services
- Members and supporters
- Partners and volunteers
- Outcomes
Connected data and process
A clear authoritative organisation identity across the connected process, one set of definitions, and funding connected to the activity it supports, without duplicating either side.
Business Central and ERP
- Finance
- Budgets
- Purchasing and payments
- Projects
- Funds and dimensions
- Reporting
- A clear authoritative organisation identity across the connected process
- Programme visibility
- Funding connected to activity
- Reporting without reconstruction
Platform fit
Use each platform for the process it is best suited to manage.
Organisations vary enormously in size, service model and funding structure. The combination should follow the operating problem, and each element is qualified rather than assumed.
Business Central
The financial and operational core.
- General finance, AP and AR, budgets, purchasing, cash, projects, dimensions and reporting
- Qualified against funding model, restriction requirements and programme or project reporting
- Qualified against integrations, payment and fundraising model, multiple entities, approval and audit
- Service workflows should connect to it, not be forced inside it
Dynamics 365 CRM
The relationships and service work around the mission.
- Beneficiaries, members, supporters, funders, partners, volunteers and service processes
- Cases, services, activities and communication held as structured records
- Role-based access designed from purpose, role and need rather than convenience
- Not every stakeholder type belongs in one unrestricted data model
Power Platform
Focused apps, forms and automation where they earn their place.
- Referral forms, case apps, volunteer apps and grant workflows
- Approvals, Power Automate and Dataverse as the shared data layer
- Power Pages where external access is genuinely required
- Not every process needs a custom app
Business Central does not automatically solve charity finance, and CRM does not automatically make every stakeholder type belong in one data model. Both are qualified against the operating model, the funding model and the access design.
Leadership view
Could leadership answer these without asking several teams to reconcile the answer?
If not, the issue may be data and process connection rather than another report.
- How many people are waiting for service?
- Which services are under pressure?
- Which funding programmes support which activity?
- What evidence is missing?
- Which grants need reporting soon?
- Where are partner referrals waiting?
- What is the financial position by programme?
- Which memberships are due for renewal?
- Where is demand changing?
CEO and trustees
Can leadership connect resources, activity and outcome?
- Mission delivery
- Demand
- Funding
- Financial sustainability
CFO and finance
Can Finance connect the money to the activity it exists to support?
- Restricted funds
- Budget vs actual
- Commitment
- Grant reporting
Service leader
Where does the service need attention today?
- Demand
- Caseload
- Waiting work
- Partner referrals
Membership and supporters
Is the relationship live, lapsing or at risk?
- Renewal
- Engagement
- Giving
- Preferences
Funding and fundraising
What have we committed to funders, and can we evidence delivery?
- Programmes
- Conditions
- Reporting dates
- Renewals
Data and reporting
Do we agree on definitions before we argue about numbers?
- Ownership
- Definitions
- Quality
- Access
Data
The organisation should not need to rebuild its own story every reporting cycle.
Ownership, definitions, quality, role-based access and governance decide whether reporting is an extract or a project.
- Duplicate records
- Inconsistent definitions
- Spreadsheet reporting
- Manual reconciliation
- Disconnected case data
- Unclear ownership
- Historic data quality
Data & AI
AI is most useful when it reduces administrative burden or improves understanding.
Automate repetitive coordination before automating judgement. Automation should give staff more capacity for work that needs a person.
Potential AI use cases
- Summarise case history
- Draft routine communication
- Find approved knowledge
- Extract information from documents
- Prepare reporting context
- Identify missing information
Automate coordination first
- Acknowledgements
- Reminders
- Approvals
- Task creation
- Escalation
- Partner notification
- Document routing
- Reporting preparation
Human accountability
Technology can support the process. People remain accountable for important decisions.
Service eligibility, safeguarding, funding, service access, case decisions and any clinical or care decision stay with the people responsible for them. AI should not decide who receives support.
Potential use cases
What would service leaders want to know earlier?
These are potential use cases to assess against your data, not deployed models. We do not claim model availability for Not for Profit organisations.
- Where will service demand exceed capacity?
- Which case types are increasing?
- Where is backlog likely to grow?
- Which programmes are approaching funding pressure?
- Where are volunteer or resource constraints emerging?
Each idea is qualified against
- Decision
- Data
- Signal
- Timing
- Actionability
- Baseline
- Risk
- Cost
Wider service networks
Where Not for Profit connects to wider service ecosystems.
Local authorities, healthcare, commissioners, funders and other providers may all be part of delivering a single outcome. These routes are relevant only where the operating problem genuinely matches.
Care and clinical management depth is qualified through Healthcare & Care rather than offered as a routine Not for Profit next step.
Delivery route
The right route depends on how much is still undecided.
Eight routes, chosen from the situation rather than the sector. Capabilities such as Data & AI and Predictive Intelligence sit outside this list.
Signals that recovery is the honest answer
- CRM not adopted
- Case management fragmented
- Finance reporting weak
- Integration broken
- Backlog growing
- Customisation excessive
- Implementation stalled
- Data untrusted
Confidence gates
Four points where confidence is re-confirmed.
Each gate is a decision point rather than a milestone. Narrowing scope at a gate is a legitimate outcome.
Gate 1
Before commitment
Mission and operating model confidence
Not for Profit is not one operating model, so the first gate confirms which one this organisation actually runs.
Confirmed at this gate
- Organisation archetype and any combination of models
- People and stakeholder model
- Service, membership and fundraising activity
- Funding, grants and contracts
- Partners and volunteers
- Outcome definitions and data sensitivity
- The intended business outcome
Decision
Proceed on the agreed model · Narrow the scope to what is understood · Assessment first where uncertainty is material · Transform first where the operating model is undecided
Gate 2
Before design is fixed
Platform and governance confidence
Architecture is confirmed against ownership of each important fact rather than against a product preference.
Confirmed at this gate
- CRM, Business Central and Power Platform boundaries
- Forms, portal, fundraising and payment systems
- Specialist systems that should remain authoritative
- Data ownership, integration and monitoring
- Security, information sharing and licensing
- Reporting requirements and first-release scope
Decision
Proceed with the agreed architecture · Re-scope the first release · Retain a specialist system and integrate it · Adopt a different architecture
Gate 3
Before go-live is planned
Operational proof
Prove the scenarios relevant to this organisation, including the exceptions, rather than a demonstration path.
Confirmed at this gate
- Service example: referral, assessment, service, partner, outcome
- Membership example: join, member, engagement, renewal
- Fundraising example: supporter, donation, finance, stewardship
- Grant example: award, restriction, activity, evidence, report
- Security and partner access behave as designed
- Finance connection, reporting and exception handling
Decision
Proceed to go-live planning · Remediate the failed scenarios · Re-test
Gate 4
Before go-live
Go-live confidence
Go-live is ready when live services, funding commitments and relationships can continue without losing ownership, access control or financial meaning.
Confirmed at this gate
- Organisations, people, live cases and open referrals
- Grants, budgets and funding context
- Members, renewals, supporters and recurring commitments
- Payment integrations, volunteers and partners
- Forms and portal channels
- Security, trained users and support arrangements
Decision
Go · No-go · Controlled deferral of a defined scope
Shared responsibility
We can configure the process. The organisation has to own the policy and decisions behind it.
The organisation owns
- Service policy and eligibility
- Safeguarding policy
- Funding rules and grant restrictions
- Finance and accounting treatment
- Outcome framework
- Supporter and fundraising policy
- Membership rules
- Information-sharing policy
- Access and retention decisions
- Data validation and UAT
- Adoption and cutover decisions
InteliSense may provide where agreed
- Process design
- Architecture
- Configuration and development
- Integration
- Migration
- Security-design support
- Testing
- Reporting
- Cutover support
- Risk visibility
Cutover
Live services, funding and relationships continue through the change.
Go-live is ready when live services, funding commitments and relationships can continue without losing ownership, access control or financial meaning.
- Live cases and open referralsOwner, status and next action carried across without losing the history that matters.
- Members and renewalsCategory, term, payment position and renewal date remain correct on day one.
- Supporters and recurring commitmentsPreferences, permissions and recurring giving continue without interruption.
- Grants and funding commitmentsAward, period, restriction, budget and reporting dates remain traceable.
- Payment and fundraising integrationsReconciliation continues through the change rather than resuming after it.
- Partners and volunteersAccess, assignment and in-flight work move with the same restrictions.
- Finance positionBudgets, commitments and programme position keep their financial meaning.
Foundations
Migration, integration, adoption and licensing are decided together.
These are qualification areas for a Not for Profit context. The detail lives on the dedicated pages rather than being repeated here.
Data migration
Organisations, contacts, beneficiaries, cases, members, supporters, volunteers, partners, grants, programmes, active funding commitments, open tasks, preferences and permissions where appropriate, and relevant finance and reference data.
Historical information should move because there is a defined operational, legal or reporting need, not simply because it exists.
Explore Data MigrationIntegration
Website, forms, fundraising platform, payment service, events, communications tools, Microsoft 365, finance and banking interfaces, specialist case platforms and partner systems.
For each material integration establish purpose, authority, data, timing, failure behaviour, monitoring and support owner.
Explore IntegrationAdoption
Understand impact, involve users, validate, prepare, train, practise, go live, support and review across service staff, membership, fundraising, volunteers, finance, data and managers.
A connected platform will not create connected information if every team keeps its real record somewhere else.
Explore AdoptionLicensing and identity
Full-time staff, part-time staff, volunteers, external partners, portal users and occasional users behave differently.
Identity, access and licence design should be qualified together, particularly where volunteers, partners or external users are involved.
Explore Licensing
How delivery works
Validate against real scenarios, not abstract requirements.
Small teams, part-time roles, volunteers, multiple locations and high service pressure all shape how a platform should be introduced.
Understand
Service, membership, fundraising, funding and finance as they actually operate today.
Design
Operating model, data, partners, funding and security decided before configuration.
Validate
Tested against real scenarios, not abstract requirements.
Build
Configured against agreed decisions, with customisation kept deliberate.
Connect
Integrations to website, forms, payment, finance, Microsoft 365 and partner systems where real.
Migrate
What is needed for purpose, retention and operational need, not everything ever recorded.
Prove
Demonstrated with the people who will use it daily.
Adopt
Small teams, part-time roles and volunteers need a system that removes work.
Operate
Support keeps agreed capability running. Improvement is a separate, justified decision.
After go-live
Running, reviewing and improving are different commitments.
Keeping the platform working, checking it still fits the organisation and changing it are separate decisions with separate owners.
No change is a valid outcome of a review.
How we work
Standardise the administration. Protect the human service.
Standardise the administration, protect the human service
Referral, case status, approvals, funding records and reporting definitions can be standard. Professional judgement should not be.
Keep accountability human
Eligibility, safeguarding, funding and service access decisions stay with the people responsible for them.
Design access before designing features
Sensitive information needs clear ownership, role-based access and auditability, including for partners and volunteers.
Reduce coordination work first
Administrative capacity is a strategic resource. Duplicate entry and status chasing consume it quietly.
Respect the delivery reality
A system that adds administration to front-line work will struggle to gain trust, whatever it does in a demonstration.
Separate running from improving
Support keeps capability operating. Customer Success reviews alignment. Optimise executes a justified change. No change is a valid outcome.
Where would you start?
Tell us the kind of organisation and where the pressure sits.
Four questions. The answers are carried into any conversation, so nothing needs repeating, and no platform is selected from a form.
Indicative signal
Answer the questions and we will show a likely starting point. This is orientation rather than a recommendation, and we do not decide platform fit or acceleration from a form.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Customer evidence
Published membership-organisation evidence.
Our verified evidence in this space is a published customer video with the British Society of Lifestyle Medicine, which demonstrates Dynamics 365 delivery with a membership organisation. It does not evidence charity service delivery, beneficiary management, grant management, fundraising, restricted funds or case management, and we do not present it as though it does.
Customer voice
Implementing D365 for the British Society of Lifestyle Medicine.
Membership organisation
British Society of Lifestyle Medicine
Implementing D365 for the British Society of Lifestyle Medicine
Approved logo usage exists for other organisations, but our central evidence model does not attach verified industry, engagement, platform or outcome information to a logo. We do not infer Not for Profit delivery scope from an organisation's name.
Common questions
Questions Not for Profit leaders ask.
Keep more effort focused on the mission
Where is administration getting in the way of the mission?
If service, membership, supporter, funding, finance or reporting information is becoming harder to coordinate, we can help understand where the operating model needs to connect more clearly.