SOP — New-Customer Setup in Action1 (Organization Group + Agent Enrollment)

Purpose

Stand up a newly-signed customer in Action1 (CyberSuite’s RMM leg) so that:

1. The customer’s endpoints live in a dedicated Action1 Endpoint Group named with the CS Client ID, separated and reportable per firm, and
2. The Action1 agent is enrolled on every disclosed endpoint (Windows + Mac), ready to deploy Huntress, run security scripts, inventory, patch, and remote.

This is the Action1 technical procedure behind the Day 0 setup in SOP 6 — Customer Onboarding (operations-only/strategy/06-operations-sops-manual.md) and complements the customer-facing Onboarding Plan. Run once per new customer at Day 0. It does not restate the 14-day plan.

Replaces the Syncro setup. This SOP replaces the retired syncro-new-customer-setup.md. The RMM leg moved from Syncro to Action1 per operations-only/strategy/syncro-decommission-and-function-map.md. The full setup/deploy/test mechanics live in runbooks/action1-setup-and-deployment.md — this SOP is the per-customer onboarding wrapper around it.

The triad. Action1 is the RMM leg only. EDR = Huntress (Action1 deploys the agent; Huntress detects). Enforced MDM / config-profiles = Intune (Business Premium) or Mosyle free (Mac fallback). Action1 configures security via scripts, not enforced profiles.

Where ticketing / email-to-ticket went (read this)

Syncro’s email-to-ticket function is not in Action1 — Action1 has no PSA/ticketing. Inbound customer email now lands in the shared-inbox model (operations-only/strategy/syncro-decommission-and-function-map.md, row 7 — an open gap, interim model). Do not look for an Action1 equivalent of the old per-domain Email Rule, branded auto-ack, or ticket-number reply; those mechanics are retired, not ported. Likewise the recurring deliverable tickets (Monthly Report / QBR / etc.) that Syncro fired are now an open gap (dashboard/engine-driven cadence — same doc, row 8); see the Deliverables note below.

Prerequisites

• Action1 admin access — CyberSuite’s own Action1 account (never PDR’s; [[project_two_company_tooling_separation]]), with MFA on the admin login (it is god-mode over endpoints; store the credential in 1Password).
• Signed Order Form (trigger; SOP 5 → SOP 6).
• CS Client ID CS-#### minted in HubSpot (the firm’s Company → cs_client_id). This is the universal key everything routes to — HubSpot, PandaDoc, reports, evidence, and the Action1 group name.
• Customer’s exact billing/legal name (for the group label).
• Endpoint inventory from the Deployment Questionnaire (Windows PC count / Mac count, OS, access path).
• Huntress deployment keys for this org (ACCT_KEY, ORG_KEY — from the Huntress portal → the customer org’s deploy page).

Procedure

Part A — Create the customer Endpoint Group (the org boundary)

Action1’s free tier organizes endpoints with Endpoint Groups (Enterprise tiers add multi-org). One group per customer keeps each firm’s endpoints separated and reportable, mirroring the old Syncro Organization boundary.

1. In Action1 → create a manual or dynamic Endpoint Group for the customer, named with the CS Client ID first — e.g. CS-1042 — Smith & Associates. The CS-#### prefix makes the group sortable, searchable, and consistent with every other system. (See runbooks/action1-setup-and-deployment.md Part 1.)

2. Carry the customer record’s data in HubSpot, not Action1. Action1 has no rich custom-field/org-record model like Syncro. The canonical customer data — CS Client ID, MSP Plan/tier, SLA, platform (M365/Workspace), primary domain, main POC, HubSpot Deal ID, go-live date — lives on the HubSpot company record. Action1 carries only what it needs to operate: the group name (CS-####) and the Huntress ACCT_KEY/ORG_KEY used at deploy time.

   Data	Where it lives now
   CS Client ID CS-####	HubSpot company property cs_client_id (minted) + Action1 group name
   MSP Plan / tier (Standard / Defense / Sentinel)	HubSpot company record
   SLA (e.g. Defense+ = 1-hour customer notification)	HubSpot company record
   Platform (M365 / Workspace)	HubSpot company record
   Primary domain	HubSpot company record
   Main POC	HubSpot company record
   HubSpot Deal ID	HubSpot (native)
   Go-live date	HubSpot company record
   Huntress ACCT_KEY / ORG_KEY	Used at deploy time; store the credential pair in 1Password, keyed by CS-####

3. Confirm a baseline group CS-INTERNAL exists for CyberSuite’s own + test machines (one-time; runbooks/action1-setup-and-deployment.md Part 1).

Part B — Enroll the Action1 agent on every disclosed endpoint

Deploy the agent to all endpoints in the inventory, into the customer’s CS-#### group. Full mechanics: runbooks/action1-setup-and-deployment.md Part 2.

4. Windows (silent, machine-wide, elevated): Action1 → Endpoints → Add Endpoints → Windows for the org-specific install command (curl download + msiexec /quiet). Push via existing tooling/GPO or run locally. Confirm each endpoint appears under the correct CS-#### group within a few minutes.
5. macOS (.pkg, root): Action1 → Endpoints → Add Endpoints → macOS for the .pkg + sudo installer -pkg <Action1Agent>.pkg -target /. On Intune/Apple-MDM-managed Macs, push the .pkg as a managed package and pre-approve the TCC/Full Disk Access prompts via an Intune/MDM PPPC profile; on unmanaged Macs, approve manually. Confirm check-in.

Part C — Apply the per-tier policy set

6. Assign the customer’s Action1 policy set (patch / monitors / automations) — assign the Windows and/or Mac policy per asset OS, defined in the RMM Policy Set SOP (patch SLA Critical 7d / High 30d / Standard 60d; after-hours maintenance window; the FileVault-OFF / BitLocker-OFF critical alert). Set the per-customer maintenance window from the Deployment Questionnaire.

Part D — Deliverables (note — not an Action1 function)

7. Recurring deliverable scheduling is no longer an RMM ticket. In Syncro this was a recurring ticket per tier deliverable. That is now an open gap (syncro-decommission-and-function-map.md row 8) handled by the dashboard/engine cadence + shared inbox/scheduler per the Deliverable Cadence & Triggers table. Until that mechanism is owned, schedule the customer’s tier deliverables (Monthly Report; Defense+: QBR, Tabletop, Compliance Posture/Mapping; Annual Renewal + Delta) via the agreed interim cadence and record delivery as the proof-of-delivery artifact keyed by CS-####. Do not look for an Action1 feature here.

Verification

1. Group exists: the CS-#### — <billing name> Endpoint Group is present in Action1.
2. HubSpot record populated: the company record carries cs_client_id, MSP Plan, SLA, platform, domain, POC, Deal ID, go-live date.
3. Agents checked in: every disclosed endpoint from the inventory appears in the correct CS-#### group and is reporting (runbooks/action1-setup-and-deployment.md Test #1).
4. Policy applied: the OS-correct policy set is assigned to the group (patch SLA + maintenance window + monitors live).

Rollback / if it goes wrong

• Endpoint didn’t check in: confirm the install ran elevated (Windows) / as root (Mac), the network reached app.action1.com, and (Mac) the TCC/Full Disk Access approval completed. Re-run the install; do not move on with a missing endpoint.
• Endpoint landed in the wrong group: move it to the correct CS-#### group; verify dynamic-group rules aren’t mis-scoped.
• Wrong/duplicate group created: rename or remove before endpoints accumulate against it; keep the CS-#### prefix authoritative.
• Escalation owner: Founder. Action1’s own support via the Action1 portal.

Related

• SOP 6 — Customer Onboarding (operations-only/strategy/06-operations-sops-manual.md); SOP 12 (Vendor Coordination), SOP 13 (Support Escalation).
• Onboarding Plan (customer-facing).
• Action1 Setup, Deployment & Test Runbook — the full RMM-leg mechanics this SOP wraps.
• RMM Policy Set SOP — Part C policy set + patch SLA + monitors.
• Engineer Deployment Runbook — the end-to-end deployment sequence (step 1 is this SOP).
• operations-only/strategy/syncro-decommission-and-function-map.md — what each retired Syncro function moved to (ticketing + recurring deliverables are open gaps).

---

Status: draft — the per-customer procedure is sound, but it depends on two open gaps from the decommission (the shared-inbox ticketing model and the recurring-deliverable cadence mechanism) and on the Action1 policy templates per tier being built. Move to done once the policy set is templated and the deliverable-cadence mechanism is owned. Re-verify cited Action1 UI paths against the live console when they change.