Atlas project production

MDM Integration Automation (Mosyle)

Provide the Mosyle API tooling layer used by district reconciliation workflows while keeping the broader write-enabled production sync separate and explicit.

Internal-only entry. Do not publish externally without review.
Type
Component
Lifecycle
Active
Last touched
2026-03-24
Visibility
Internal

Purpose

Document the Mosyle API component layer without confusing it for the full district reconciliation workflow that uses it.

Current state

The registry now shows that the stronger production evidence is the wrapper workflow syncing Mosyle and Snipe-IT every 30 minutes. This page therefore describes the underlying API tool, not the whole operational process.

Next step

Keep this page focused on component behavior and document live production reconciliation, host ownership, and write-enabled scope on the separate workflow page.

Interfaces

Inputs
  • Mosyle API credentials
  • CSV inputs for bulk updates
  • device identifiers
Outputs
  • device export CSVs
  • Mosyle attribute updates

Reality to Action trace

Reality Ingestion

Not in scope.

Canonical Storage

Not in scope.

Automation Engines

Not in scope.

Human Interfaces

Contributes in this stage.

Operational Adoption

Contributes in this stage.

Core workflow

TBD. Document the 5-10 steps that define the core workflow.

Data integrity and contracts

Source of truth rules

  • Mosyle remains canonical for MDM-side device state.
  • This CLI is an operational interface to Mosyle and should not be treated as the system of record itself.

Safe handling

  • Restrict Mosyle credentials and exported CSVs.
  • Limit bulk-update usage to approved operators.
  • Document wrapper-level write scope before broadening production use.

Operational notes

Reliability posture

The API component is useful and active, but the production question now sits at the wrapper-workflow level: which hosts run it, with what write scope, and against which asset classes.

Observability

  • CLI stdout/stderr
  • API response details
  • CSV artifacts created by wrapper workflows

Security and privacy

Mosyle credentials, assignment context, and CSV artifacts should remain internal and restricted to device operations staff.

Dependencies

Upstream
  • Mosyle API access
  • device inventory identifiers
  • wrapper workflow decisions
Downstream
  • Mosyle to/from Snipe-IT Asset and Tag Sync

Ownership

Owners

Technology Services, Josh Barton

Users

Technology Services, device operations maintainers

MDM Integration Automation (Mosyle)

Operational Notes

  • This page intentionally stays at the component layer. The registry now makes clear that the stronger production evidence sits above it in the scheduled Mosyle to/from Snipe-IT Asset and Tag Sync workflow.
  • The component still matters because it defines the Mosyle API boundary used by wrapper scripts and other automation. What Atlas should avoid is treating a reusable CLI as if it were the whole district workflow.
  • When documenting live operations, capture host ownership, write-enabled scope, and asset-class boundaries on the workflow page rather than here.

Registry Alignment

  • Related registry entry: INT-071.
  • Registry clarified: the strongest production evidence points to wrapper scripts such as snipeit_sync_mosyle.sh and snipeit_sync_mosyle_asset_tags.sh, not to this component alone.
  • Validation gaps: workflow-level host ownership, write-enabled scope, and asset classes in scope still need documentation.