Connecting a XenForo community to the systems around it
A community holds members, permissions, content and activity, and other systems frequently want some of it. The question is which parts, who owns them, and what happens when the other system is unavailable.
A community's data is more entangled than it looks
Members are not just records: they have permission groups, secondary groups, ranks and state. Content is not just posts: it has visibility, moderation state, prefixes and ownership. An integration that treats any of these as a simple field will produce a community where the permissions do not match the other system's view of who someone is, and the symptom appears as access that is wrong in one direction or the other.
- Members have to be created or updated in two systems
- Access to a resource is granted in one system and expected in another
- A subscriber or membership status has to be reflected in forum permissions
- Content has to reach a system outside the community
- An integration was built and permissions do not match between the two sides
- Departed members retain access because nothing removed it
- Activity or reputation has to feed a reporting system
- The community is one part of a larger platform and the two are joined by hand
The people who usually bring us this problem
A community that is part of a larger platform
The forum is one surface among several and the same people have accounts in more than one place.
Someone connecting membership to access
A subscription, licence or entitlement has to determine what a member can reach.
Someone whose community data has to reach another system
Activity, content or reputation needs to feed something outside the forum.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Permissions are not a field, they are a model
XenForo determines what a member can do from their primary group, their secondary groups, per-node permissions and any explicit overrides. An integration that writes a single role onto a member will not reproduce that, and the mismatch shows up as access that is too broad or too narrow — usually discovered by someone who should or should not have it.
Membership state has an end as well as a beginning
An integration that grants access when a subscription starts but does not remove it when the subscription ends produces a community with access that never expires. Expiry, cancellation, refunds and lapses are each a case, and they are the cases an integration is most likely to omit.
Content visibility is not the same as content existence
Threads and posts carry visibility, moderation state and ownership. Exposing content to another system without carrying those means the other system shows things the community deliberately hides, which is a disclosure problem rather than a display one.
The community is frequently the system of record
For identity, for reputation and for discussion, the forum often holds the authoritative version. Where that is the case it is stated, because an integration that treats the community as a downstream copy will overwrite the thing it should be reading from.
Capabilities
Each of these is work we carry out, not an area we advise on.
Establishing what is authoritative, per field
Identity, permissions, membership state, content, reputation — which system owns each, and which follows. On a community that is part of a larger platform this is the first decision, and getting it wrong produces data that changes depending on which system was written to last.
Member and identity integration
Creating and updating accounts, and deciding whether authentication is delegated. Where a single sign-on is used, what the community keeps locally and what it reads from elsewhere is a deliberate choice rather than a default.
Permission and group mapping
How the other system's model of who someone is maps onto the community's groups, secondary groups and per-node permissions — including the cases where one does not express what the other does, and what happens then.
Membership lifecycle, including the end
Grant, renew, lapse, cancel, refund and removal, each with a defined effect on the member's access. The end of the lifecycle is the part integrations omit and the part that produces a community where access never expires.
Content endpoints and visibility
Reading content out of the community, carrying its visibility and moderation state so the receiving system does not display what the community hides. Including the content types an integrator usually forgets: profile posts, resource entries, media.
Event emission
Notifying other systems when something happens that they care about — a registration, a membership change, a post, a report — with signature verification and replay protection on the receiving side.
Failure handling for a community
What happens when the other system is unavailable: whether a registration still completes, whether a permission change is queued, and what the member experiences in the meantime. On a community the member-facing behaviour of a failed integration is the part that gets noticed.
Reconciliation
A way to compare the two systems' view of membership and permissions, and correct the differences. Without it there is no way to answer the question that follows any incident: who currently has access they should not, and since when.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Establish the authoritative source per field first
Identity, permissions, membership and content. On a community that shares users with other systems the answer differs per field, and an integration built without that decision overwrites the authoritative side from the copy.
Model the permission mapping explicitly
How each state in the other system corresponds to the community's groups and permissions, written down, including the states that have no equivalent. The mapping is the integration's actual specification, and an implicit one produces access that is wrong in a way nobody can trace.
Treat expiry as a first-class case
Every grant has an end, and the integration handles it: lapse, cancellation, refund, removal. This is the single most commonly omitted part of a membership integration and it is the one with a security consequence rather than a cosmetic one.
Carry visibility with content
Anything read out of the community carries its visibility and moderation state, so the receiving system can honour them. Content extracted without them is a disclosure of things the community deliberately restricts.
Design the member-facing failure behaviour
What a member sees when the other system is unavailable, and whether their action still completed. On a community, a registration that half-succeeds is a support problem, and it is decided in advance rather than discovered.
Build reconciliation alongside the integration
A comparison of membership and permissions across the two systems, runnable on demand. It is what makes the integration verifiable, and it is what produces the list after an incident instead of an investigation.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Design
- The authoritative source per field, written down
- Authentication approach, and whether the community keeps its own credentials
- The permission and group mapping, including states with no equivalent
- The full membership lifecycle, including expiry and removal
- Content endpoints with visibility and moderation state carried
- Failure behaviour, including what the member experiences
Implementation
- Member and identity integration
- Permission and group synchronisation, both directions as decided
- Membership lifecycle handling, including the end
- Event emission with signature verification and replay protection
- Queueing and retry for operations that cannot complete immediately
- Credentials stored outside the codebase and rotatable
Verification
- Reconciliation between the two systems, run and any differences resolved
- Failure cases exercised: the other system unavailable, slow, returning errors
- Permission mapping checked against real accounts, not a fixture
- Expiry and removal verified by exercising them
- What the integration does not cover, stated plainly
Architecture and technology
What a community integration usually involves
- Member identity and account creation
- Permission groups, secondary groups and per-node access
- Membership state: active, lapsed, cancelled, removed
- Content: threads, posts, and the types usually forgotten
- Activity and reputation, where they feed another system
- Events the other system needs to know about
- Authentication, where the community does not keep its own
How community integrations go wrong
- Writing a single role where the community determines access from several groups
- Granting access with no path that removes it
- Extracting content without its visibility or moderation state
- Treating the community as a copy when it holds the authoritative identity
- Failing during a registration and leaving the member half-created
- No reconciliation, so a divergence is discovered rather than detected
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The community needs custom functionality
Add-ons that extend the platform's own behaviour.
XenForo add-on developmentThe community is being moved
Converting from another platform and reconciling the result.
Forum migration to XenForoThe integration is with a bespoke source
Importers for data models no existing tool covers.
Custom forum importersFrequently asked
Do you have an integration you can point to?
No. Our published forum engagements are platform and infrastructure work rather than integrations, and presenting one of those as an integration reference would be claiming a case we do not have. What the page describes is specific to the platform and therefore checkable: how XenForo determines access from several groups rather than one role, why membership expiry is the case integrations omit, and why content has to be extracted with its visibility. That is more useful to an integrator than a logo.
Can we use XenForo as a single sign-on provider?
It can act as the identity holder, and whether it should depends on what else is in the estate. Where the community is the main place people have accounts, keeping identity there and letting other systems read it is reasonable. Where there is a corporate directory or a platform-wide account system, the community usually follows that instead and keeps its own profile data. What matters is deciding which system owns identity, because an integration that treats the community as a downstream copy will overwrite the authoritative record.
How do permissions map between systems?
Explicitly, and it is the integration's real specification. XenForo determines what a member can do from a primary group, any number of secondary groups, per-node permissions and explicit overrides — so a single role written from another system will not reproduce it. The mapping states what each state on the other side corresponds to here, including the states that have no equivalent and what happens to them. Without that written down, the result is access that is wrong in a direction nobody can trace.
What happens when a subscription lapses?
That is handled explicitly, because it is the case integrations most often omit. Grant, renew, lapse, cancel, refund and removal each have a defined effect on the member's access, and the expiry path is the one with a security consequence — an integration that grants access but never removes it produces a community where people keep what they stopped paying for. It is also why reconciliation is built alongside: after any incident the question is who currently has access they should not, and since when.
Can we read content out of the forum?
Yes, and the part that matters is carrying visibility with it. Threads and posts have visibility, moderation state and ownership, so content extracted without those means the receiving system displays things the community deliberately restricts — which is a disclosure problem rather than a display one. The content types are also easy to under-count: profile posts, resource entries and media are all content, and integrations that read only threads and posts typically miss them.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.