El curso no es la unidad de integración que crees

Si llevas tiempo integrando plataformas educativas, la conversación empieza casi siempre con la misma pregunta:

¿Cómo sincronizamos los cursos?

Es una pregunta razonable. También suele ser una de las primeras decisiones que hipotecan la arquitectura.

Creamos el curso en el LMS, copiamos su identificador al CRM, lo relacionamos con una edición en el ERP, lo usamos para matricular usuarios, asociar contenidos, recibir calificaciones, calcular progreso, emitir certificados y construir informes. Durante un tiempo todo encaja. El diagrama es sencillo, las primeras pruebas pasan y la integración parece resuelta.

Hasta que aparece la realidad.

El mismo contenido se imparte en tres convocatorias. Dos grupos comparten actividades, pero no profesorado. Una persona cambia de cohorte. El LMS duplica el curso para el siguiente periodo. Una herramienta externa trabaja con una actividad concreta, no con el curso entero. El departamento de formación quiere medir una competencia que se desarrolla en varios cursos. Y el certificado debe sobrevivir aunque el aula virtual se archive o desaparezca.

Entonces descubrimos que course_id no era una frontera de negocio. Era un atajo.

El curso es muy útil para organizar la docencia dentro de un LMS. Pero no representa, por sí solo, todo lo que una integración necesita saber sobre identidad, acceso, contexto, actividad, evidencia, evaluación o acreditación.

Esta es la tesis del artículo:

El curso es una vista operativa del aprendizaje. No debería ser el contrato universal de todo el ecosistema.

Por qué el curso se convirtió en la unidad de integración

No ocurre por falta de criterio. Ocurre porque el curso es la entidad más visible.

Tiene nombre, fechas, participantes, profesores, contenidos y calificaciones. En Moodle organiza actividades, grupos, roles y finalización. En un SIS o ERP puede parecer equivalente a una asignatura, una acción formativa o una edición. Para un equipo que necesita conectar dos sistemas con rapidez, resulta tentador establecer una correspondencia directa:

curso del ERP <-> curso del LMS <-> curso de la herramienta externa

La equivalencia funciona mientras los tres sistemas compartan el mismo modelo del mundo. El problema es que casi nunca lo hacen.

Para el catálogo, “Arquitectura de software” puede ser una definición reutilizable. Para el ERP, puede ser una acción formativa financiada. Para el LMS, una instancia impartida entre septiembre y diciembre. Para el SIS, una asignatura con varios grupos. Para una herramienta LTI, un contexto desde el que se lanza un recurso. Para el sistema de credenciales, un conjunto de criterios que permite reconocer un logro.

El nombre se parece. La entidad no.

Cuando un único identificador intenta representar todas esas realidades, la integración empieza a acumular excepciones: sufijos por convocatoria, campos personalizados, tablas de equivalencias manuales, cursos “padre”, cursos “plantilla”, categorías que en realidad representan programas y estados que significan algo distinto en cada sistema.

No tenemos un problema de sincronización. Tenemos un problema de modelado.

Curso, asignatura, edición, grupo y contexto no son sinónimos

Una distinción pequeña puede evitar muchos años de deuda técnica: separar la definición de una experiencia formativa de su oferta concreta.

La definición describe algo relativamente estable: título, objetivos, competencias, carga estimada, idioma, versión curricular o requisitos. La oferta representa su ejecución: convocatoria, fechas, docentes, estudiantes, modalidad y calendario.

Después aparecen otras unidades:

• El grupo organiza a una parte de los participantes dentro de una oferta.
• La actividad es aquello que la persona hace: una prueba, una simulación, una lectura, una práctica o una sesión.
• El recurso es el objeto utilizado o lanzado para realizar esa actividad.
• El intento representa una ejecución concreta de la actividad.
• La evidencia registra qué ocurrió y con qué resultado.
• El logro o la credencial reconoce algo que puede trascender una oferta e incluso una plataforma.

El propio estándar LTI 1.3 utiliza la palabra context allí donde podríamos esperar “course”. Lo hace de forma deliberada: un contexto puede ser un curso, pero también un grupo, una sección, un proyecto u otra colección de recursos con usuarios y roles comunes. Además, dentro del mismo contexto, cada integración concreta se diferencia mediante su resource_link_id. Es decir, el estándar ya nos está avisando de que “el curso” es demasiado ambiguo para expresar toda la relación entre plataforma, herramienta y recurso.

Esta distinción entre definición y oferta no es solo un asunto técnico. Es también de gobierno de datos educativos: una misma guía docente, un mismo programa y un mismo logro pueden desplegarse muchas veces, en muchas plataformas, sin perder su identidad curricular.

En Moodle esta tensión también se ve con claridad. El curso es un contenedor fundamental, pero muchas interacciones relevantes ocurren en las actividades. Su arquitectura ofrece APIs separadas para matriculación, grupos, competencias, finalización de actividades, calificaciones, eventos y servicios externos, además de una librería xAPI que los logstores aprovechan para emitir declaraciones a un LRS. El propio diseño técnico de la plataforma refleja que no existe una única unidad capaz de resolver todos los intercambios.

La pregunta correcta no es “qué curso sincronizo”

La pregunta correcta es:

¿Qué hecho de negocio necesita conocer el otro sistema?

Según la respuesta, la unidad de integración cambia.

Este cambio parece semántico, pero afecta a toda la arquitectura. Si el objetivo es conceder acceso, quizá no necesites replicar un curso completo: necesitas una asignación vigente. Si quieres devolver una nota, no estás sincronizando el curso: estás actualizando un resultado asociado a una actividad evaluable. Si quieres analítica, un porcentaje global de progreso aporta mucho menos que una secuencia de evidencias contextualizadas.

El curso puede seguir apareciendo como contexto. Lo que deja de hacer es monopolizar el contrato.

LTI tampoco integra “cursos” de la forma en que solemos contarlo

Es habitual resumir LTI diciendo que “conecta una herramienta externa con un curso del LMS”. Es una explicación útil para empezar, pero incompleta para diseñar una solución real.

LTI 1.3 distingue varias piezas:

• La plataforma, normalmente el LMS.
• La herramienta, que ofrece la funcionalidad externa.
• El deployment, que identifica el despliegue de esa herramienta en la plataforma.
• El contexto, donde existen usuarios, roles y recursos relacionados.
• El resource link, que identifica el enlace concreto desde el que se lanza una experiencia.
• El usuario y su rol, que dependen del contexto del lanzamiento.

LTI Advantage añade servicios con límites todavía más precisos. Names and Role Provisioning Services —NRPS— permite consultar las membresías de un contexto y sus roles. Assignment and Grade Services —AGS— trabaja con line items, resultados y puntuaciones. Un line item suele equivaler a una columna del libro de calificaciones y representa una actividad evaluable para un conjunto de usuarios; no es “la nota del curso” como bloque indivisible.

Esta separación es importante. Una herramienta puede necesitar saber quién pertenece al contexto, lanzar varios recursos distintos y devolver resultados a varias columnas. Reducir todo eso a una relación curso_origen -> curso_destino elimina información que después intentaremos reconstruir con reglas frágiles.

Si te toca implementar esto en Moodle —OIDC, JWT, Deep Linking, NRPS, AGS— el detalle técnico lo tienes en la guía práctica de integración LTI Moodle y el encuadre arquitectónico en LTI no es un plugin: es una frontera de producto.

Además, la identidad que recibe la herramienta no debería resolverse con el correo electrónico. En LTI, el identificador estable del usuario es el sub emitido por la plataforma para esa relación de seguridad. El correo puede no compartirse, puede cambiar y no es una clave técnica fiable. Otra vez, el modelo correcto importa más que la comodidad del primer mapeo.

OneRoster separa incluso el curso de la clase

OneRoster ofrece otra pista útil. En su modelo, course y class no son la misma entidad. De forma simplificada, el curso describe una oferta académica y la clase representa una instancia concreta en la que se producen las matrículas. El estándar separa además los servicios de rostering, gradebook y recursos.

Eso permite formular contratos diferentes para problemas diferentes:

• Personas, organizaciones, periodos, clases y matrículas para el aprovisionamiento.
• LineItems, resultados, categorías y escalas para las calificaciones.
• Recursos asignados a clases, cursos o usuarios para la distribución.

La lección arquitectónica no es que OneRoster deba utilizarse en todos los proyectos. Su ámbito principal sigue siendo el intercambio entre SIS, LMS y aplicaciones educativas, especialmente en K-12. La lección es que un estándar creado específicamente para interoperar tampoco intenta resolverlo todo con una tabla de cursos.

Para la analítica, la unidad es la evidencia

Imagina dos estudiantes con un 75 % de progreso en el mismo curso.

El primero ha completado todas las actividades obligatorias y solo le falta una lectura opcional. El segundo ha abierto tres recursos, ha fallado dos intentos de una evaluación crítica y no ha entregado la práctica. El porcentaje coincide. La historia de aprendizaje no.

Cuando queremos comprender qué ha ocurrido, la unidad relevante deja de ser el curso y pasa a ser el evento o la evidencia:

• Qué persona realizó la acción.
• Sobre qué actividad u objeto.
• En qué momento.
• Dentro de qué contexto.
• Con qué resultado.
• Qué sistema produjo la evidencia.
• Qué versión del contenido o criterio estaba vigente.

xAPI expresa experiencias mediante declaraciones —su modelo de datos está publicado además como estándar IEEE 9274.1.1— y Caliper Analytics define perfiles para modelar actividades como evaluaciones, lecturas, anotaciones, medios, foros, sesiones o uso de herramientas. Los dos enfoques parten de una idea parecida: la analítica necesita eventos con significado, no únicamente el estado agregado de un contenedor.

Esto no significa enviar cada clic sin criterio. Un lago lleno de eventos irrelevantes no es una arquitectura de aprendizaje; es una factura de almacenamiento. Conviene distinguir entre telemetría de producto, eventos técnicos y evidencias con valor educativo o de negocio.

video.paused puede ser útil para analizar una experiencia multimedia. assessment.passed puede activar una regla de progreso. competency.demonstrated puede justificar una credencial. Los tres eventos tienen granularidad y consecuencias diferentes.

El certificado tampoco pertenece realmente al curso

Otro síntoma aparece cuando la credencial depende físicamente del aula virtual.

Una persona completa una formación, obtiene un certificado y, meses después, el curso se reinicia, se duplica, se archiva o se elimina por una política de retención. Si el logro solo existe como un registro interno asociado a ese course_id, hemos confundido la ejecución con el resultado.

La credencial debería poder conservar:

• Quién la recibió.
• Qué logro reconoce.
• Qué criterios se cumplieron.
• Qué evidencias lo respaldan.
• Quién la emitió.
• Cuándo se emitió y, si procede, cuándo caduca.
• Cómo puede verificarse.

Open Badges 3.0 modela credenciales verificables y permite expresar logros, evidencias, criterios, fechas y emisores. La credencial puede haber nacido tras completar actividades en un curso, pero no debería quedar prisionera de su contenedor técnico.

Y cuando el logro es académico o necesita agruparse, aparece la pieza complementaria: el Comprehensive Learner Record (CLR 2.0), diseñado para crear, transmitir y representar el conjunto de logros de una persona a lo largo del tiempo. Open Badges reconoce el logro; CLR consolida el historial. Ambos tratan la credencial como entidad con identidad propia, no como un campo del curso.

Una competencia es todavía más evidente: puede construirse durante varias asignaturas, una práctica profesional, un proyecto y una evaluación externa. Obligarla a pertenecer a un único curso es adaptar el aprendizaje al esquema de la base de datos, no al revés.

Un caso realista: el onboarding que parecía un curso

Pensemos en un programa de onboarding para una empresa con varias sedes.

El catálogo contiene una definición llamada “Seguridad y trabajo remoto”. Recursos Humanos asigna el itinerario a cada nueva incorporación. Moodle crea una edición mensual con fechas y tutores. Dentro del aula hay un contenido H5P, una simulación externa lanzada por LTI y una sesión síncrona. La simulación devuelve una puntuación. La asistencia llega desde otra plataforma. Al cumplirse los criterios, se emite una credencial válida durante doce meses.

Si el curso es la única unidad de integración, aparecen preguntas incómodas:

• ¿Qué ocurre cuando Recursos Humanos asigna el programa antes de que exista el curso del mes?
• ¿Cómo reutilizamos la misma simulación en distintas ediciones sin duplicar su identidad?
• ¿Dónde registramos un segundo intento realizado fuera del LMS?
• ¿Cómo distinguimos finalización, aprobado y asistencia?
• ¿Qué pasa si la persona cambia de edición?
• ¿Qué identificador conserva la credencial cuando el curso se archiva?

Un modelo más sano separaría, al menos, estas entidades:

learning_definition     Seguridad y trabajo remoto, versión 3
offering                Edición de septiembre de 2026
membership              Persona X como participante de la edición
activity                Simulación de phishing, versión 2
activity_attempt        Intento 4f8… de la persona X
evidence                Simulación superada con 87/100
achievement             Conducta segura ante phishing
credential              Logro emitido, verificable y válido 12 meses

learning_definition     Seguridad y trabajo remoto, versión 3
offering                Edición de septiembre de 2026
membership              Persona X como participante de la edición
activity                Simulación de phishing, versión 2
activity_attempt        Intento 4f8… de la persona X
evidence                Simulación superada con 87/100
achievement             Conducta segura ante phishing
credential              Logro emitido, verificable y válido 12 meses

Moodle puede seguir siendo el sistema que organiza la impartición. No tiene que ser el propietario de todas las identidades ni el archivo definitivo de todas las evidencias.

Diseñar contratos por capacidad, no por pantalla

Una integración robusta empieza definiendo capacidades y ownership. ¿Quién crea la identidad? ¿Quién decide el acceso? ¿Quién conoce la pertenencia a un grupo? ¿Quién es autoridad sobre una calificación? ¿Dónde se conserva la evidencia? ¿Quién emite la credencial?

Una matriz sencilla suele revelar contradicciones antes de escribir código:

No se trata de implantar todos los estándares a la vez. Se trata de evitar que un único endpoint llamado /sync-course esconda siete responsabilidades distintas.

La arquitectura puede empezar de forma mucho más modesta: contratos separados, identificadores estables y una tabla clara de propiedad. Eso ya supone una mejora enorme frente a un proceso nocturno que copia cursos completos y decide, en cada ejecución, qué verdad debe imponerse.

Los identificadores son parte del dominio

Muchos fallos de integración atribuidos a las APIs son, en realidad, fallos de identidad.

Un curso se restaura desde una copia de seguridad y recibe un nuevo identificador. Una actividad se duplica. Un usuario cambia su correo. Una edición nueva reutiliza el código comercial del año anterior. El sistema externo conserva identificadores que parecían permanentes, pero solo eran claves locales.

Conviene trabajar con tres niveles:

1. Identificador canónico del dominio. Representa la entidad que queremos mantener estable: definición, oferta, actividad, logro o persona.
2. Identificador local de cada sistema. Moodle, el ERP o la herramienta externa mantienen sus propias claves.
3. Relación de correspondencia. Una tabla explícita registra qué entidad local representa a qué entidad canónica, con sistema, versión, estado y fechas de vigencia.

El resultado no tiene por qué ser un gran Master Data Management. Puede ser un registro de correspondencias pequeño y bien gobernado. Lo importante es no fingir que todos los course_id significan lo mismo.

Tampoco conviene usar campos mutables como clave: correo, nombre corto, título o código mostrado al usuario. Son buenos atributos de búsqueda. No son una identidad duradera.

Un evento útil no debería llamarse course.updated

course.updated parece un evento razonable hasta que alguien pregunta qué ha cambiado.

¿El título? ¿Las fechas? ¿El profesorado? ¿Una matrícula? ¿Una actividad? ¿La finalización de un alumno? Los consumidores terminan solicitando el objeto completo y comparándolo con una copia anterior. Hemos convertido un evento en una señal para ejecutar otra sincronización masiva.

Los eventos de dominio deberían expresar hechos que un consumidor pueda entender y procesar de forma idempotente:

• learning.offering.published.v1
• learning.membership.activated.v1
• learning.activity.completed.v1
• learning.assessment.graded.v1
• learning.achievement.awarded.v1
• learning.credential.revoked.v1

Un evento interno de finalización —no un ejemplo literal de xAPI ni de Caliper— podría tener este aspecto:

{
  "event_id": "evt_01J6Y8Q3N5",
  "event_type": "learning.activity.completed.v1",
  "occurred_at": "2026-06-18T10:42:31Z",
  "actor": {
    "id": "person_8421"
  },
  "context": {
    "offering_id": "offering_2026_06",
    "group_id": "group_valencia_02"
  },
  "activity": {
    "id": "activity_phishing_sim_v2",
    "attempt_id": "attempt_4f8c"
  },
  "result": {
    "status": "passed",
    "score": 87,
    "score_max": 100
  },
  "source": {
    "system": "phishing-simulator",
    "local_id": "run_99381"
  }
}

{
  "event_id": "evt_01J6Y8Q3N5",
  "event_type": "learning.activity.completed.v1",
  "occurred_at": "2026-06-18T10:42:31Z",
  "actor": {
    "id": "person_8421"
  },
  "context": {
    "offering_id": "offering_2026_06",
    "group_id": "group_valencia_02"
  },
  "activity": {
    "id": "activity_phishing_sim_v2",
    "attempt_id": "attempt_4f8c"
  },
  "result": {
    "status": "passed",
    "score": 87,
    "score_max": 100
  },
  "source": {
    "system": "phishing-simulator",
    "local_id": "run_99381"
  }
}

La oferta sigue presente, pero como contexto. La unidad principal del hecho es la actividad completada por una persona. El evento puede repetirse sin duplicar efectos si event_id y attempt_id se tratan correctamente. También puede evolucionar mediante una versión explícita del contrato.

Qué suele romperse cuando el curso manda demasiado

Hay varios anti-patrones que aparecen una y otra vez:

1. El curso como agregado infinito

Cada cambio obliga a volver a enviar participantes, recursos, notas y progreso. El payload crece, los conflictos se vuelven difíciles de aislar y una modificación pequeña invalida una gran parte del estado.

2. La matrícula como permiso eterno

Estar matriculado en un curso se utiliza como única prueba de entitlement. Pero una persona puede necesitar acceso antes de la edición, conservarlo después o perder solo una licencia concreta sin abandonar el contexto.

3. La finalización como booleano universal

completed = true mezcla haber recorrido un contenido, cumplir criterios, aprobar una evaluación, asistir a una sesión y obtener una certificación. En cuanto el negocio necesita distinguirlos, el booleano deja de servir.

4. La nota global como evidencia

Una calificación final es una proyección útil, no el historial de aprendizaje. No permite reconstruir intentos, criterios, versiones o decisiones manuales.

5. El correo como identificador

Funciona en la demo y falla con cambios de dominio, alias, cuentas duplicadas, minimización de datos y herramientas que no reciben PII.

6. La sincronización completa como mecanismo de recuperación

Un cron nocturno vuelve a copiarlo todo “por seguridad”. Termina siendo la única forma de corregir inconsistencias, pero nadie puede explicar qué modificación provocó cada cambio ni qué sistema tenía autoridad. Y conviene repetirlo: no toda la deuda técnica debe pagarse. Por eso la migración siguiente va por capas y no exige reescribir el ecosistema.

7. El LMS como propietario accidental

Como el curso vive en el LMS, el LMS acaba decidiendo identidades, vigencias, credenciales y estados que pertenecen a otros dominios. La plataforma deja de ser un componente y se convierte en la base de datos informal de toda la organización.

Cuándo sí es razonable integrar a nivel de curso

El objetivo no es desterrar el curso. Sería absurdo: sigue siendo una unidad valiosa para impartir, navegar, administrar y resumir.

Trabajar a nivel de curso puede ser adecuado para:

• Crear una oferta en el LMS desde un sistema académico.
• Aplicar una plantilla inicial de contenidos y configuración.
• Archivar o cambiar el estado operativo de una edición.
• Obtener indicadores agregados para un cuadro de mando.
• Realizar copias de seguridad, restauraciones o migraciones técnicas.
• Gestionar configuraciones que realmente afectan a todo el contexto.

La diferencia está en no convertir esas operaciones en el único lenguaje disponible. El curso debe ser una de las unidades del modelo, no la unidad que absorbe todas las demás.

Una estrategia de migración sin rehacerlo todo

Si hoy existe una integración centrada en cursos, no hace falta sustituirla con una plataforma de eventos, un LRS y seis estándares en el próximo sprint. Se puede avanzar por capas.

Paso 1. Inventariar los significados ocultos

Revisa qué contiene realmente la sincronización actual. Separa creación de oferta, matrículas, roles, recursos, finalización, calificaciones, evidencias y certificados. Probablemente el “curso” sea solo el sobre que los transporta.

Paso 2. Definir autoridad y claves estables

Para cada dato, establece qué sistema manda y qué identificador sobrevive a duplicados, restauraciones y cambios de periodo. Documenta las correspondencias locales.

Paso 3. Extraer el primer contrato específico

Elige el punto que más incidencias produce. Puede ser la membresía, la devolución de notas o la emisión de certificados. Dale un contrato, un ciclo de vida y errores propios.

Paso 4. Introducir idempotencia y trazabilidad

Cada operación debería tener una clave idempotente, un origen, una fecha efectiva, una versión de contrato y un identificador de correlación. La pregunta “¿por qué este usuario aparece aquí?” debe poder responderse sin revisar cuatro bases de datos a mano.

Paso 5. Mantener reconciliación, pero acotada

Los eventos pueden perderse y los sistemas pueden quedar temporalmente desalineados. Conserva procesos de reconciliación, pero ejecútalos por entidad y periodo, no como una copia ciega de todo el curso.

Paso 6. Adoptar estándares donde reduzcan acoplamiento real

LTI 1.3 puede resolver lanzamiento seguro y contexto. NRPS puede aportar membresías. AGS, intercambio de resultados. OneRoster, aprovisionamiento entre SIS y LMS. xAPI o Caliper, evidencias y analítica. Open Badges, credenciales verificables. Adoptarlos por etiqueta, sin comprender el problema que resuelven, solo cambia una integración propietaria por una implementación frágil de un estándar. Esta priorización por impacto encaja con una gestión estratégica de la plataforma: no todo se paga, ni todo se paga al mismo ritmo.

Siete preguntas para revisar tu arquitectura

Antes de crear el siguiente endpoint de sincronización, conviene responder:

1. ¿El “curso” representa una definición estable o una edición concreta?
2. ¿Qué debería sobrevivir cuando esa edición se duplica, restaura o archiva?
3. ¿La integración necesita todo el contexto o solo una actividad, membresía, evidencia o resultado?
4. ¿Quién es propietario de cada dato y quién puede corregirlo?
5. ¿Los identificadores son canónicos o pertenecen a una instalación concreta?
6. ¿Podemos procesar dos veces el mismo mensaje sin duplicar matrículas, notas o certificados?
7. ¿Podemos explicar el estado actual reconstruyendo su trazabilidad?

Si varias respuestas dependen de “mirar el course_id en Moodle”, probablemente el modelo esté pidiendo una frontera más precisa.

El curso es contexto, no destino

El curso seguirá siendo una pieza central del LMS. Agrupa personas, recursos, actividades, reglas y conversaciones de una forma que docentes y estudiantes entienden. No hay nada malo en ello.

El problema aparece cuando trasladamos esa comodidad de interfaz a toda la arquitectura y esperamos que CRM, SIS, ERP, herramientas LTI, analítica, RR. HH. y credenciales compartan exactamente el mismo concepto.

No lo comparten.

Una integración madura distingue la identidad de la membresía, la definición de la oferta, el recurso de la actividad, el intento del resultado y la evidencia de la credencial. Después relaciona esas piezas mediante contratos explícitos, sin perder el contexto en el que ocurrieron.

La próxima vez que alguien pregunte “¿cómo sincronizamos los cursos?”, quizá la mejor respuesta no sea una API.

Quizá sea otra pregunta:

¿Qué necesita saber realmente el otro sistema y cuál es la unidad más pequeña que conserva ese significado?

Ahí suele empezar la interoperabilidad de verdad.

Preguntas frecuentes

Referencias técnicas

• Learning Tools Interoperability Core Specification 1.3, 1EdTech.
• LTI Names and Role Provisioning Services 2.0, 1EdTech.
• LTI Assignment and Grade Services 2.0, 1EdTech.
• OneRoster 1.2 Standard, 1EdTech.
• Caliper Analytics, 1EdTech.
• Experience API specification, ADL Initiative / IEEE 9274.1.1‑2023.
• Open Badges, 1EdTech.
• Comprehensive Learner Record, 1EdTech.
• Moodle 5.1 API Guides, Moodle Developer Resources.

¿Y en tu arquitectura?

¿En tu arquitectura el curso sigue siendo la unidad que lo conecta todo? Revisa una sola integración y separa contexto, membresía, actividad, resultado y evidencia. Es frecuente descubrir que el problema más costoso no estaba en la API, sino en una entidad que significaba demasiadas cosas.

Si tu ecosistema depende de un course_id omnipresente y quieres redibujar fronteras sin detener la operación, te cuento cómo lo trabajo en consultoría Moodle y EdTech o me escribes por contacto.