El objetivo no es aprender Zoho. Es desarrollar criterio arquitectónico.
Un sistema de aprendizaje aplicado que convive con tu trabajo: 4-5 horas de foco semanales.
Una progresión desde fundamentals hasta architecture leadership. Cada semana produce un artefacto.
Business · Data · CRM · Integration · Security · Governance. La arquitectura vive en la intersección de todas.
Progreso por fase
Cuántas semanas de cada fase completaste.
Seis reglas que se convierten en tu sistema operativo profesional
Antes de cualquier decisión técnica, estos principios filtran la opción correcta. Si violas uno, tienes que justificarlo por escrito.
Cada fase sube el nivel de abstracción
De entender arquitectura a defender decisiones. Haz clic en cada fase para ver sus semanas.
Las 12 semanas en detalle
Cada semana es un sprint: aprende → diseña → autoevalúate → entrega. Marca tus tareas y tu quiz; todo queda guardado en tu navegador.
12 artefactos que demuestran competencia
No son horas de estudio: son muestra de capacidad. Descarga la plantilla, rellénala y márcala como entregada.
Prioriza criterio sobre herramientas
Un mapa honesto de dónde poner tu energía. Las 5 estrellas son tu identidad; el resto es contexto.
| Área | Prioridad | Resultado esperado |
|---|
Una semana de 4-5 horas que funciona
La formación debe convivir con el trabajo. Sprints de 60 minutos, no maratones de weekend.
CRM Architecture Blueprint
El entregable final integra todo el roadmap en una arquitectura de referencia defendible.
Definition of Done
Rúbrica de defensa
| Criterio | Nivel 1 · Reconoce | Nivel 2 · Decide | Nivel 3 · Defiende |
|---|---|---|---|
| Comprensión de negocio | Repite el requerimiento | Lo traduce a problema + NFRs | Cuantifica impacto y trade-offs |
| Modelo de datos | Nombra entidades | Define IDs y ownership | Explica Source of Truth y versionado |
| Integraciones | Enumera sistemas | Elige patrón y lo justifica | Anticipa failure modes y reintentos |
| Gobierno | Menciona convenciones | Diseña ownership y change control | Defiende excepciones con evidencia |
| Escalabilidad | Sabe que existe | Hace capacity assessment | Identifica primer punto de fallo |
Tu resultado al día 90
No sólo «sé Zoho». Puedes decir: «Entiendo el negocio, modelo los datos, diseño la solución, defino las integraciones, establezco governance y defiendo los trade-offs».
Integraciones para onboarding de socios (B2B)
Mapa completo de lo que puede tocar Zoho CRM en un flujo de alta de partners. Tu stack actual: ● AIprise para KYB de socios y KYC de representantes legales.
El pipeline de onboarding, etapa por etapa
Cada tarjeta: qué ocurre, cómo se implementa en Zoho, con qué se integra y qué patrón usar (conceptos de las semanas 4-6 aplicados a tu caso real).
Todas las integraciones posibles, por categoría
Filtra por dominio. «Tu stack» marca lo que ya tienes; el resto es candidates para el roadmap.
Patrón de integración por etapa (regla de diseño)
| Etapa | Patrón | Razonamiento | Failure mode y mitigación |
|---|---|---|---|
| Crear perfil de negocio (KYB) | Asíncrono + callback | El registry lookup y AML tardan segundos o minutos; el usuario no debe esperar | Callback no llega → poller programado como respaldo |
| KYC de representantes | Link hosted asíncrono | El oficial completa cuando puede (doc + liveness + face match); sesión con expiración | Sesión vencida → re-emitir link y notificar |
| Consulta de estado | Síncrono (GET) | El comité revisa en vivo y necesita respuesta inmediata | Límite de API → cachear veredicto en CRM |
| Decisiones y resultado final | Evento (Blueprint) | Cada verificación completada mueve el estado del socio con auditoría | Evento duplicado → dedupe por callback_event_id |
| Alta de proveedor en ERP | Batch / cola | Sólo socios aprobados; tolera latencia; debe ser transaccional | ERP caído → reintentos con DLQ visible |
| Monitorización continua | Asíncrono programado | Sanciones y PEP cambian; revisar por ciclo, no en request | Falta de refresh → SLA + alerta |
Estas seis filas son el entregable 06-integration-architecture.md aplicado a tu proyecto. Si cambias un patrón, documenta el porqué en un ADR (semana 11).
AIprise × Zoho CRM — Deluge por API
KYB de socios y KYC de representantes legales vía la API REST de AIprise, con funciones Deluge dentro de Zoho CRM.
Mapeo de resultados AIprise → CRM → Blueprint
| Resultado AIprise | Campo CRM | Estado siguiente | Acción |
|---|---|---|---|
verification_result: passed | Verificación → Completada / Aprobado | Socio → «Pendiente firma» | Enviar contrato (e-sign) |
failed + status_reasons | Completada / Rechazado | Socio → «Rechazado» | Email con motivo; no exponer score interno |
review o AML hits | En_revisión | Socio → «Comité» | Tarea 4-eyes al equipo de compliance |
Sesión expirada (session_expiry_time) | Vencida | Socio → «KYC pendiente» | Re-emitir link y notificar al representante |
| Error técnico (5xx / timeout) | Fallo_técnico | Socio → sin cambio | Reintentos; si persiste, DLQ + alerta |
Seguridad y PII
- La API key vive solo en Connections; el zapikey del webhook es un secreto (rotarlo si se filtra).
- Nunca loguees ni copies imágenes de documentos al CRM: en CRM van veredictos, IDs de sesión y timestamps.
- Valida
X-HMAC-SIGNATUREantes de procesar cualquier callback. - Retención y borrado definidos en el data dictionary (semana 8); scopes de OAuth de CRM al mínimo.
Idempotencia y reintentos (semana 5)
client_reference_idcon id de CRM (Socio|<id>) para no crear perfiles duplicados.callback_event_idúnico en el módulo Verificaciones: el evento repetido se descarta.- Retry solo a errores «de sistema» (429/5xx/timeout) con backoff; los 4xx no se reintentan.
- El poller programado es el respaldo del webhook: la verdad final vive en el resultado, no en el evento.
Checklist de salida a producción
Se guarda en tu navegador. Cuando completes las 12, habrás cerrado el círculo de los conceptos W4-W6-W8 en tu proyecto real.
Recursos filtrables
Un stack compacto para consultar durante los 90 días. No intentes leerlo todo: aplícalo a tu caso.