Journey and Meritura
A focused handoff. A clear boundary.
Journey holds the provider’s learner context. Meritura holds the assessment organisation’s operating context. Their connection should move the approved information needed for the job while keeping each organisation’s responsibilities clear.
Available to evaluate · supported scope and configuration confirmed in a walkthrough
Meritura is assessment-operations software for awarding organisations and EPAOs. It supports operating records and human decisions; it is not an assessment organisation, a regulator or a promise of recognition or a particular result.
UK-hosted, GDPR-compliant
Illustrative workflow
Follow the work through Meritura by Journey.
Review readiness
Accept, query or return the submitted material through an owned intake decision.
Why the boundary matters
Send what assessment needs, with an owner.
A provider may hold a broad learner record, including information that does not belong in an assessment handoff. A readiness exchange should define its purpose, the approved material and the organisation receiving it. It should not grant unrestricted access to the source system.
Meritura’s repository describes a versioned contract over authenticated HTTP; the products do not share direct database access. For a buyer, the important result is a recognisable case reference, a controlled intake decision and a practical way to resolve a question.
- The provider prepares and authorises the appropriate readiness material.
- The assessment organisation reviews intake and accepts, queries or returns it.
- Each side retains the reference and ownership needed to follow the work.
- Outcome or lifecycle information returns only through the configured, supported route.
A useful exchange record
Make the acknowledgement meaningful.
An attempted send and an accepted assessment case are different states. Agree which acknowledgement confirms receipt, which decision confirms acceptance and what the sender sees if the receiving organisation needs a correction.
The current implementation includes feature-gated connection behaviour. Ask the team to demonstrate the approved organisation binding, supported contract and return path in the environment you intend to use. Do not infer activation from the presence of an integration page.
| Point in the handoff | What to confirm |
|---|---|
| Before sending | Permitted organisations, purpose, required fields and approved evidence. |
| On receipt | Shared reference, receipt acknowledgement and duplicate handling. |
| At intake | Accepted, queried or returned state, with a reason and owner. |
| During correction | Where the update is made and how the receiver identifies the current version. |
| After a released outcome | Supported return event, correlation and acknowledgement in the configured route. |
Test the normal and the uncertain path
A handoff should survive a query.
Begin with a fictional readiness pack that contains the agreed material. Follow it from provider approval to assessment intake. Verify that both organisations can identify the same handoff and that the recipient can make the appropriate intake decision.
Then introduce an incomplete item or a repeated delivery. Ask what the sender sees, whether another case is created, who receives the query and how the corrected material is associated with the original reference. The same question should remain answerable if one side was temporarily unavailable.
People keep their authority
An integration does not make the assessment decision.
Provider readiness is an input to the assessment operation. It does not replace the receiving organisation’s intake, allocation, quality or result-release responsibilities. Permissions and decision ownership should remain understandable on both sides.
Assess a connection against the particular organisations, workflow and records involved. Agree how access is revoked, how an unresolved delivery is investigated and what manual action is appropriate during an outage. These are implementation questions to resolve before relying on the connection.
Bring the right brief
Define the handoff before requesting credentials.
A useful first brief identifies the provider and assessment organisations, the starting event, the minimum data, the required acknowledgement and the owner of failures. Include the return information you need and any timing constraints.
Use minimised sample data for the initial discussion. Agree approved processing arrangements and the authorised environment before using personal learner information. TechGeek can help scope a connected workflow; the product teams should confirm the exact capabilities and activation route.
Questions before the next step
A clearer view of Meritura by Journey.
Do Journey and Meritura share one database?
The current Meritura repository describes separate systems exchanging versioned contracts through authenticated HTTP. The connection is an agreed information boundary, not unrestricted access to the other product’s database.
Is the connection automatically active for every organisation?
No. The current product material and code describe approved organisation bindings and configuration-dependent behaviour. Confirm activation, supported contract and return behaviour for the organisations involved.
Does a delivery acknowledgement prove that an assessment case was accepted?
Not necessarily. Receipt, validation and an intake decision are distinct stages. Agree which state each acknowledgement represents and how a query or rejection is handled.
Make the next conversation useful
Start with the work.
Explore the fit.
Bring your workflow, the people involved and the decisions you need to make.