Integrations Atlas relies on today
Atlas (org management) is not isolated; it depends on several shared platform systems.Events
Atlas uses org-hosted events via the sharedEvent model:
- Public listing:
GET /:orgId/events(inorgRoutes) - Org leader tooling + analytics:
/org-event-management/:orgId/...
hostingType: 'Org'hostingId: <orgId>
Forms (member join applications)
WhenOrg.requireApprovalForJoin is enabled and Org.memberForm is set:
- join requests create a
FormResponsesnapshot - that snapshot id is stored on
OrgMemberApplication.formResponse
FormFormResponse
Notifications
Join applications can notify org admins via:NotificationService.createBatchTemplateNotification(...)
Meridian/backend/routes/orgRoutes.js→/:orgId/apply-to-org
Email/SMS/Push
Org messaging supports notification fanout depending on system settings:OrgManagementConfig.messaging.notificationSettings
Meridian/backend/routes/orgMessageRoutes.js
Where to implement “SIS Integration” (future/optional)
There is no single “SIS connector” module inside Atlas today. If you need SIS imports (rosters, org directory, etc), the typical patterns are:- Backend import jobs (scripts or inngest functions) that write to:
Orgdocuments (org directory)OrgMemberdocuments (rosters)
- Admin tooling surfaced under
/feature-admin/atlasto trigger or monitor imports
- how you reconcile role assignment (
OrgMember.role) - how you keep
User.clubAssociationsconsistent - how you handle “inactive” members vs hard deletion