Docs / Pipeline / Workflow steps
Pipeline · Chapter 1 of 1

Workflow steps

The four MAS pipeline steps at operator-reference depth. Each section covers what happens on the page, which fields the packager owns, which MAS decides on its own, and what the step writes to disk before handing off to the next.

4 min read
Applies to v2.0+
Last updated 2026-07-19
PUBLISHED

The four MAS pipeline steps at operator-reference depth. Each section covers what happens on the page, which fields the packager owns, which MAS decides on its own, and what the step writes to disk before handing off to the next.

1. Capture #

Purpose. Turn the raw installer file (.msi, .exe, .msp, or a setup folder) into a structured Capture record — a set of fields that the Build step needs to instantiate the PSADT template.

MAS decides.

  • Installer technology (MSI / InnoSetup / NSIS / MSIX / plain EXE) via file-signature and metadata inspection.
  • MSI properties (ProductCode, ProductVersion, UpgradeCode, Manufacturer, ProductName) via the Windows Installer API.
  • EXE version and publisher via the file's version-info resource.
  • MAS Catalog match: UpgradeCode → vendor+name → SHA-256 hash, in that order. First hit wins; the row prefills silent-switch and detection-rule defaults.

Packager owns.

  • Every field, always. Every capture field is editable — the Catalog supplies defaults, the packager confirms or overrides.
  • The Silent switch if the installer is a plain EXE that MAS could not identify (Catalog miss + no InnoSetup/NSIS signature).
  • Optional metadata: internal name, custom category tag, custom ownership field.

Writes. No files. The Capture record lives in memory until Build persists it as the workspace's _capture.json.

2. Build #

Purpose. Instantiate the PSADT v4 template with the Capture record, apply the packager's chosen cmdlets, and write a valid PSADT workspace to disk.

MAS decides.

  • Template layout — folder structure, filenames, script skeletons — follows the PSADT v4.1.8 shape embedded with the app.
  • One Install step is always generated from the Capture (Start-ADTMsi Process for MSI, Start-ADTProcess for EXE). If the Catalog supplies a matching Uninstall command, an Uninstall step is generated too.
  • Filesystem layout of the workspace: %LOCALAPPDATA%\MilochApplicationStudio\workspaces\<slug>\{Files, SupportFiles, AppDeployToolkit, ...}.

Packager owns.

  • Any additional cmdlet inserted from the Cmdlet Library (custom registry writes, service management, shortcut creation, PSADT UI prompts).
  • The Deferral / Close-Apps / Reboot toggles on the Build page.
  • The choice of custom scripts under SupportFiles\ if the package needs them.

Writes. The full workspace folder — script, payload, PSADT runtime, capture snapshot. On success the workspace becomes the handle for the Pre-Ship step.

3. Pre-Ship #

Purpose. The last human checkpoint before the package leaves the workstation. Everything set here is what the target platform will see.

MAS decides.

  • Preflight checks: workspace exists, PSADT script parses, detection rules present, package name unique on the active profile's target. A failed check blocks the Ship button.
  • Default detection rules — MSI product code for MSI packages, the registry uninstall entry that the Catalog referenced, or a file- version rule against the installer's main EXE for plain EXE packages.

Packager owns.

  • Package name. Renamed at Pre-Ship so the SCCM Application or Intune Win32App carries the final human-visible name. Defaults to <Product> <Version> <Architecture>; adjust to match the organisation's convention.
  • Detection rules. The Detection-Editor lets the packager add, edit and remove rules per package. MSI product-code, file existence + version, registry key + value, PowerShell script — all four rule types are available on both SCCM and Intune.
  • Signing. If Settings → Signing carries a certificate, the Sign-Scripts toggle applies it to Invoke-AppDeployToolkit.ps1 and every .ps1 under SupportFiles\ before the Ship step runs.

Writes. The renamed workspace folder (Pre-Ship performs an atomic rename on the workspace path). Detection rules are stored in the Memory-DB row for the package, ready for the Rollout step to attach.

4. Rollout #

Purpose. Push the package into every target the profile is configured for, and record the outcome. Rollout is the only step that talks to a remote endpoint.

MAS decides.

  • Which targets to run based on the active profile:
    • Profile has SCCM config → one SCCM job.
    • Profile has Intune config → one Intune job.
    • Profile has both → both jobs run in parallel from one Ship click.
  • Ship-queue state machine per job: Queued → Running → (Cancelled|Failed|Completed). Completed and Failed both leave the workspace untouched so the run can be retried without a rebuild.

Packager owns.

  • The final Ship click. Everything before it is reversible.
  • Optional cancel from the queue drawer. Cancel is best-effort — a cancel during the SCCM content-distribution stage will let the distribution finish (ConfigMgr owns the transaction) but abort before deployment creation.

Writes.

  • SCCM: creates or updates the SCCM Application in one New-CMApplication call, distributes content to the configured DP group via UNC copy, and (if the profile carries a default collection) creates the Deployment. The single-call app-create pattern lifts CIVersion from 4 to 2 on fresh apps.
  • Intune: packages the workspace to .intunewin, uploads it via the Microsoft Graph beta endpoint, attaches detection rules, and posts the default assignments the profile defines. Assignment autopost was introduced in the 2026-07-18 Ship-flow refactor (Etappe 6) — details in the profile section.

Every stage of every job produces a Memory-DB audit row with the hash-chain linkage.

Up next · Settings Reference
Required settings
MAS ships with sensible defaults for almost everything. Two settings have to be configured explicitly before the pipeline can complete: an active profile and, optionally but frequently, a code-signing…
→