Solutions · Apps · Membership management

Membership management on Microsoft Dataverse — the app behind the suites.

Our industry solutions for associations, chambers and education institutes are not separate products but the same apps in a different arrangement. This page describes one of them on its own: membership management. It holds persons, memberships, roles and contributions — and it can be introduced by itself, long before any further area is added.

Microsoft Dataverse as the data foundation 1,000–50,000 members target size Can be introduced on its own without the other areas Business Central for documents and tax

What the app holds

Six things that make up a membership.

The most common mistake when rebuilding membership management is to keep the membership as a field on the person. That loses everything which makes it a thing in its own right — and you notice only when someone joins for the second time.

Person and organization kept apart

A natural person and a member organization are two different things, and both can be members. Contacts belong to the organization, not to the membership — when the organization's management changes, the membership remains untouched.

Membership as an object in its own right

With start, end, status and history. Someone who has been a member twice has two memberships and one person. That sounds obvious and is the point at which a rebuild inside a CRM runs into its limits.

Roles instead of fixed functions

Board, delegates, section heads, invoice recipients: freely definable and time-limited. One person can hold several roles at once, including across different memberships.

Contribution class with a calculation basis

Flat rate, revenue-dependent, by headcount or by your own formula. The class belongs to the membership, not to the person — when a member changes class, the history of earlier assessments stays readable.

Sub-structures without duplicate records

Branches, local offices, districts, regional associations, specialist sections. One organization can sit under another without any person having to be created twice.

Direct debit mandate per person

With validity, date of issue and revocation. The mandate belongs to the person who pays — who need not be the one who is a member, and that cannot be expressed in a spreadsheet.

Automation

What the app does on its own.

The contribution run

One operation across every affected membership, with contribution class, period and payment method per case. What comes out of it goes to Business Central as a claim and becomes a document there — not as a list to be typed in again.

Status change when the term ends

When a membership expires, the status changes by itself. Nobody has to keep a reminder list, and nobody writes to a former member by accident.

The recipient's language

Every message goes out in the language held against the person, based on 16 email templates. Your own staff maintain the texts.

The boundary

Where the app ends and Business Central begins.

The line runs exactly where a claim becomes a document. Everything before it belongs to the app, everything after it to Microsoft Dynamics 365 Business Central:

  • The app calculates who owes what, under which contribution class, for which period and by which payment method.
  • Business Central posts: document, VAT, SEPA direct debit, dunning, handover to accounting. XRechnung and ZUGFeRD are standard capabilities there; DATEV runs via established add-ons.

This boundary is not a technical accident but a decision with a simple reason: contribution rules change rarely, tax law constantly. When tax rules change, Microsoft should be the one to follow, not us — and you should not have to wait on our release plan because a tax rate moved. Anyone buying membership management with accounting built in is buying that wait along with it.

Where the app sits

The same app, two audiences.

Membership management is not rebuilt per industry. What differs are the areas around it and the language on the surface.

Scope

What the app is not.

A feature list says what something can do. What it explicitly does not do is often more useful — it saves you the demonstration in which it turns out you were talking past each other.

  • Not a CRM. Opportunities, quotes and pipeline belong in Microsoft Dynamics 365 Sales, if you need them. The app knows members, not leads.
  • Not an accounting system. It produces no documents, posts nothing and calculates no tax. That is deliberate, see above.
  • Not an event tool. Registration, dates and attendance belong to course and CPD management, a separate area that builds on this app.
  • Not a newsletter tool. It sends individual messages in the recipient's language, but it does not replace a dispatch system for bulk mailings.
  • Not a finished off-the-shelf product. Contribution rules differ, and the calculation basis is configured per organization. What exists is the structure underneath — not your statutes.

Frequent questions

What gets asked before implementation.

How does a dedicated membership management app differ from a CRM?

A CRM knows persons and companies, but it does not know membership. In a CRM, membership is usually approximated as a field on the person, and that loses everything which makes it what it is: period, status, history, roles, contribution class. Someone who has been a member twice, with a gap in between, has two memberships and one person — that cannot be expressed in a field. In this app, membership is therefore an object in its own right with its own lifespan. The person remains alongside it, even when no membership is running.

What does the app do itself, and what does Business Central do?

The app holds persons, memberships, roles, contribution classes and the contribution run. It calculates who owes how much and on which date. What becomes a document out of that is created in Microsoft Dynamics 365 Business Central: invoice or assessment notice, VAT, SEPA direct debit, dunning and the handover to accounting. XRechnung and ZUGFeRD are standard capabilities there; DATEV is connected via established add-ons. The boundary is deliberate: contribution rules change rarely, tax law constantly — and when tax rules change, Microsoft should be the one to follow, not us.

Can the app be introduced without the other areas?

Yes, and that is the most common starting point. Membership management is the foundation on which CPD, certification and the portal build — it does not need any of them in return. Starting here leaves you with a clean register of persons and memberships, and every further area can be added one at a time. Service management needs only the shared platform base; its link to membership management is optional.

How are several legal entities represented?

A person is created once and can hold memberships and documents in several legal entities. The association, the academy and a service company each get their own company in Business Central, while sharing one register of persons in Microsoft Dataverse. This is provided for and not a bespoke build; the question of what a second legal entity costs is worth asking of every vendor.

Who owns the data?

The data sits in your own Microsoft tenant, in Microsoft Dataverse. That is the same database Microsoft Dynamics 365 uses — not a proprietary file format you would later have to migrate out of. A full export is possible at any time, and another service provider can take the solution forward, because every building block underneath is a standard Microsoft product.

Related

While you are here — these topics fit alongside.

60-min demonstration · free

See your own register of members in the app.

An hour is enough to show membership, roles and a contribution run against your own cases — and to say which parts are configuration and which are development. Bring your membership office, your contributions team and your IT.