A catalogue can be shared across a network. The account model cannot be borrowed from employee training without deciding who acts for which organisation and what that action proves.
A dealer-network manager opens the learning portal a week before a new point of sale launches. The courses are live. The test works. The completion report is green.
Then the manager needs to assign a route to a sales assistant who works across two locations. The franchise owner asks which locations are actually ready. A certificate remains active after a learner has left the partner company. Support cannot tell whether the access issue belongs to a person, a location, or the partner itself.
The catalogue has not failed. It is simply carrying a job that was never part of the employee LMS model.
I am Anton Fokin, CEO at Qtim. We build educational platforms, LMS products, and partner accounts. This article is about the point where training for dealers and franchisees becomes an external product: one with organisations, delegated roles, certifications, and status changes around the course itself. It ends with five checks for choosing between a configured LMS and a dedicated partner layer.
The course is shared. The organisation context is not.
An employee LMS usually begins with one employer and one HR directory. The company knows who hired the learner, which team they belong to, who manages them, and when access ends. A job title, department, and manager can be enough to assign a programme and build a report.
Dealers and franchisees bring independent organisations into the same learning flow. A dealer manager may work on behalf of several locations. A franchise owner needs an aggregate view without seeing another franchise’s learners. A trainer may require a limited view of participants. A brand team may need network-level readiness, while support sees only what is necessary to resolve an incident.
Each of these people can open the same platform. They do not have the same authority, reporting scope, or reason to access the data.
That distinction is central to extended-enterprise learning. Fosway describes this audience as people outside the employer, including partner organisations, franchise workers, and contractors. They may take the same programme as employees, yet they do not sit inside one employment hierarchy.
When our team maps this product model, we place an organisation record alongside the user profile. It connects locations, authorised managers, people, programmes, statuses, and access rules. Without that record, every new partner exception becomes another group, another exported list, or another account created for the same person.
One launch creates three different jobs
Consider a product launch in a franchise network. The franchise owner needs to know whether every location can open on the agreed date. A location manager needs a checklist for the shift team. A sales assistant needs a short route: how to present the offer, answer common questions, and find support.
All three jobs may include the same course. They produce different actions after the course.
The owner reads readiness by location and watches expiring certificates. The manager assigns a route and confirms that the local team completed the required steps. The sales assistant needs only the materials and assessment that apply to the role. Giving them one generic account model makes the report look simpler while leaving the operating question unanswered.
This is the first useful distinction between employee training and an external contour: a completion record belongs to a person, while readiness may belong to a location or a partner organisation.
Completion does not prove readiness
Learning teams already face a measurement problem in virtual training. In a 2025 survey by Class, Training magazine, and Microsoft, more than 650 L&D and training professionals took part; 72% named learner engagement as their top virtual instructor-led training challenge. The survey does not measure dealer networks, so it cannot establish a result for a particular franchise programme.
It does clarify the design question. Opening a module, passing a test, receiving a certificate, and being ready to perform a business action are separate states. A network needs to decide which one changes the status of a location.
A “location ready to open” route may include owner training, a short programme for the frontline team, a document checklist, a knowledge check, and manager confirmation. A product launch route may include a sales module, a demonstration, a deadline, and an updated certificate. The LMS can record the learning steps. The surrounding product logic must say whose readiness changes after those steps are complete.
That is why we start a dashboard with the unit of accountability. Before choosing a completion-rate widget, we define whether the metric describes the learner, the location, or the partner. Otherwise each team extracts data into its own spreadsheet and reaches a different answer.
Certificates need a history, not only an expiry date
External training often controls more than knowledge. A certificate can be required before a partner sells a product, opens a location, accesses materials, or retains a status in the programme.
The rule becomes difficult when a person moves. Which certificate remains valid after a learner changes location? What happens when the person joins another partner company? Which access ends when the partner loses a status? What history should a new manager see?
These are identity and access questions with a training event inside them. NIST’s Digital Identity Guidelines separate identity proofing, authentication, and federation, and choose controls according to the risk of a particular digital service. The guidance was written for public-sector services. Its practical lesson still applies here: define the account, organisation membership, role, and permission rules before the programme depends on them.
For a partner-learning product, a certificate needs an owner, a validity period, a renewal rule, and a link to the organisation context in which it was earned. That record gives the team an auditable answer when the learner’s role or partner status changes.
A configured LMS can still be the right answer
An external layer is not a default requirement. A small partner network with one programme, simple groups, one administrator, and basic reporting may work well inside an existing LMS. The decisive factor is not the number of courses. It is the number of organisation contexts and rules that change access or business status.
The boundary appears when independent organisations, delegated management, access layers, and learning scenarios multiply. Teams then maintain partner lists outside the LMS, close accounts late, reconcile reporting from several systems, and recreate groups when a new programme or location arrives.
At that point, adding another course will not remove the pressure. Our team maps the shared entities: person, organisation, location, role, programme, certificate, and status. The map shows which functions an LMS can own and where the product needs integrations or a partner-facing account.
Five checks before opening the external contour
- Which system is the source of truth for the partner, location, and learner?
- Can one person work for more than one organisation without duplicate profiles?
- Which role can assign learning, see progress, issue exceptions, and view certificates?
- Does a certificate remain valid after a learner changes role, location, or partner?
- Which status proves that a location or partner is ready for the business event?
When these questions lead to separate account models, conflicting statuses, and routine reconciliation outside the LMS, the partner network has outgrown an employee-only access model. Map the entities and their boundaries before selecting another platform or adding another portal.
Discuss the architecture of an external learning product with us.
Top comments (0)