Plan a Moodle and WordPress arrangement by separating identity, course enrolment, role permissions and public content ownership. Decide what each system should control before selecting a connector. A successful sign-in should lead to the intended account and course access, with a clear decision about what happens when that access changes.
Which system owns each responsibility?
Begin with a boundary map. Identify where the public course description is maintained, where the learning activity takes place and which system is expected to create or recognise the person’s account. Give each responsibility a named owner and a record that can be inspected.
Use a hypothetical training course called Introduction to Workshop Records. Give it a synthetic learner and a separate staff account. The proposed exercise is to trace the learner from the public description to the intended course access; it does not assume a particular connector or claim that the integration has been tested.
Keep public copy and learning participation distinct in the brief. Ask which team can edit the description and which team decides who may participate. Record how a change in one place should be communicated to the other, including the person who checks that the two descriptions still agree.
Write down which account identifier the proposed integration uses and how it handles a person already present in either system. Ask the implementer to demonstrate that rule using training accounts, rather than relying on a familiar display name as the mapping evidence.
What does enrolment actually control?
Moodle’s enrolment API distinguishes user enrolment from role assignment. Moodle’s user enrolment record includes enrolment status and start and end dates. The Moodle 5.0 enrolment API guide gives those concepts separate records and meanings.
Moodle stores specific role assignments in relation to a context. Ask the implementer to identify the enrolment and role-assignment evidence for the training learner. Record the course, the method that created the enrolment and the relevant context. The review should explain why that person receives the intended participation rights.
Moodle supports active and suspended enrolment states. Include both states in the requirements discussion. Decide what should happen when access is paused, who authorises that change and which other access routes need assessment. The business requirement should define the intended outcome before a connector setting is selected.
Moodle’s enrolment guide says full unenrolment purges participation information and is irreversible. Make the decision about withdrawal and participation records explicit. Ask the learning administrator to explain the available route in the selected configuration and retain the decision owner. Use a test course to inspect the intended behaviour before any real participation record is affected.
Which permissions belong on WordPress?
WordPress uses roles to control what users can and cannot do on the site. WordPress calls the tasks permitted for a role capabilities. The WordPress roles and capabilities guide describes responsibilities within WordPress; those roles should be assessed on their own terms.
WordPress defines its Editor role as able to publish and manage posts, including other users’ posts. WordPress defines its Contributor role as able to write and manage its own posts but not publish them. Use those documented distinctions to decide who prepares public course copy and who may release it. Keep the learner’s participation requirements separate from the publishing responsibilities of staff.
WordPress allows its default role for new users to be configured in General settings. Ask the WordPress administrator to identify the actual configured default and any changes made by the proposed integration. Record the resulting training account’s capabilities instead of treating the default role name as complete evidence of its access.
Prepare a staff-editing exercise alongside the learner exercise. Ask a training editor to update the public course description through the intended route, and ask the learning administrator to confirm whether a related Moodle change is required. Keep the content decision and the account-access decision understandable separately.
How should identity and access changes be assessed?
For an existing training account, have the implementer demonstrate which identifier is matched and which record is created or reused. Include a deliberately similar name so the mapping rule can be examined. Record the actual account references on both sides without placing real learner data in the exercise notes.
Next, propose an account detail change and ask which system owns it. Decide whether the other system should receive the change and what evidence would show that it has done so. The answer should describe the selected integration’s behaviour, not an assumed universal synchronisation feature.
Include an access pause for the training learner. Ask the assessor to inspect the course entry route and the relevant account state using the configured process. If another route remains available, record it as a question for the learning administrator rather than silently declaring that all access has ended.
Keep a procedure for unresolved mappings. Specify who investigates a duplicate account or an enrolment that has not appeared, and which references they need. The operating instructions should give staff a way to resolve the problem without making ad hoc permission changes.
What belongs in the integration boundary register?
Use this original identity-to-enrolment register when assessing a proposed arrangement. These are questions for the chosen implementation, not a claim that WordPress and Moodle automatically provide a complete shared workflow.
| Boundary | Evidence to retain | Owner’s decision |
|---|---|---|
| Public description | Page reference and approved course wording | Who maintains the public explanation? |
| Account identity | Training account references and matching rule | Which record represents the intended person? |
| Course access | Course, enrolment method and status | Who authorises participation? |
| Permissions | Relevant role and capability evidence | What may this person do in each system? |
| Detail change | Authoritative field and observed result | Which system supplies the update? |
| Access pause | Intended restriction and assessed entry routes | Has the chosen access decision taken effect? |
| Participation records | Withdrawal decision and responsible administrator | Which records must remain available? |
Ask a second administrator to use the register to explain the training learner’s current position. They should be able to identify the intended person, the course and the outstanding access decision without guessing from a public page or a role label.
Retain the connector version and configuration references alongside the observations. When an integration changes, use the register to identify which identity, enrolment or permission questions need repeating. That creates a practical basis for controlled maintenance rather than a one-time demonstration that the two websites open.
For the wider scope, see web development or send Spout your course journey and account boundaries. Include the system that should own each decision and one representative learner path.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.