AtlasLoopOS documentation

Step-by-step guides for every product in the current catalog.

Use this page to understand prerequisites, the intended operator sequence, what to verify, and the current product boundary. Product status, application routes, capability names, and required permissions are sourced from the canonical product manifest.

Before using a Beta product: sign in, select the correct organization/workspace, confirm entitlement and required permission, configure only the providers needed by that workflow, and keep material execution behind the documented human approval and guardrail checks.
betaatlas-strategy

AtlasStrategy

Document source-backed market research, ICP, positioning, measurable goals, and a GTM play; submit it to the shared human approval gate and track the decision in Command Center.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: atlas-strategy.access.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Strategy owners, growth leads, founders, and reviewers who need product context, market evidence, ICP, positioning, measurable goals, and a governed GTM play in one workspace.

Step-by-step

  1. 1Select an entitled organization and workspace, then open AtlasStrategy.
  2. 2Complete or review the product profile so the strategy has a defined product context.
  3. 3Add market or niche research entries with source URLs, notes, trends, and competitor evidence.
  4. 4Define the priority segment, ICP, buyer roles, pains, triggers, and exclusions.
  5. 5Document positioning, measurable goals, KPIs, and operating guardrails.
  6. 6Draft the GTM play and its hypothesis, then review the complete strategy packet.
  7. 7Submit the play to the shared approval gate; an authorized reviewer approves, rejects, or requests revision.
  8. 8Verify the decision and approved-play visibility in Command Center before downstream planning.

Verify the result

  • • The product profile and research records remain scoped to the selected workspace.
  • • The submitted play contains the intended ICP, positioning, goals, evidence, and hypothesis snapshot.
  • • The approval decision appears in Command Center with the expected status and history.

Current boundaries

  • • Research is user-provided; automated external market-database research is not part of the current Beta.
  • • Approval marks a play ready for controlled planning and does not launch execution.
  • • The workflow does not contact prospects, publish content, or spend budget automatically.
  • • Availability depends on an eligible organization entitlement and a healthy deployment.
betaatlassocial

AtlasSocial

Plan and approve social content through permissioned workspace data, then publish approved X/Twitter posts immediately or through the durable scheduled queue when an account is authorized. Facebook, Instagram, and LinkedIn remain draft/schedule-only placeholders.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: atlassocial.access.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Content and growth teams that need idea generation, platform-specific drafts, explicit approval, scheduling, and controlled X/Twitter publishing inside a workspace.

Step-by-step

  1. 1Select an entitled organization and workspace.
  2. 2Review the imported content sources that AtlasSocial can use for idea generation.
  3. 3If X/Twitter publishing is required, connect the workspace account through the configured OAuth flow.
  4. 4Generate post ideas from selected source IDs or the available source set.
  5. 5Generate platform captions from an idea or source and choose the intended tone.
  6. 6Review each draft and explicitly approve or reject it.
  7. 7For an approved X/Twitter draft, publish now or schedule it for the durable provider-backed queue.
  8. 8Review the scheduling calendar and draft status; treat Facebook, Instagram, and LinkedIn as draft/schedule placeholders until separate publishing integrations exist.

Verify the result

  • • The selected workspace shows the intended content sources and generated drafts.
  • • The X/Twitter connection reports connected before a real publish action is attempted.
  • • Approved drafts show the expected approval and publish/schedule status in the workspace.

Current boundaries

  • • X/Twitter is the only real publishing provider in the current Beta.
  • • Facebook, Instagram, and LinkedIn remain draft/schedule-only placeholders.
  • • Publishing still requires an approved draft and a configured provider connection.
  • • The product does not grant unsupervised publishing permission.
betaatlasloop

AtlasLoop

Research canonical accounts, create and move versioned opportunities, record append-only revenue events, and run human-approved outreach with explicit SendGrid delivery evidence. Availability requires an eligible workspace and deployment configuration; full CRM activity management, autonomous follow-up, reply classification, FX conversion, and production service levels remain outside this Beta.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: revenue:read.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Sales and revenue operators who need canonical accounts, a versioned opportunity pipeline, append-only revenue evidence, and human-approved outreach without a second identity model.

Step-by-step

  1. 1Select an entitled organization and workspace.
  2. 2Create or review a canonical AtlasData account and contact.
  3. 3Create an opportunity with amount, close date, stage, and working context.
  4. 4Move the opportunity through the versioned kanban and inspect stage history.
  5. 5Record expected, recognized, collected, refunded, or adjustment revenue evidence as appropriate.
  6. 6Draft outreach and submit it for a separate human approval decision.
  7. 7Send explicitly through configured SendGrid and review provider delivery or bounce evidence when the deployment is configured.

Verify the result

  • • Stage changes append history and stale concurrent writes are rejected rather than silently overwritten.
  • • Recognized and collected revenue remain separate from opportunity pipeline value.
  • • Outreach has a human approval record before an explicit send action.

Current boundaries

  • • AtlasLoop is a limited Beta rather than a full CRM.
  • • SendGrid sending and provider feedback require deployment-specific configuration.
  • • No opportunity movement, revenue recognition, outreach, or follow-up occurs autonomously.
  • • Reply ingestion, generalized activity management, AI forecasting, and FX conversion are outside the current Beta.
betaatlaspipe

AtlasData

Create tenant-scoped data sources, upload UTF-8 CSV files, preview detected columns and types, review every mapping, validate rows, import normalized GTM records, and inspect synchronization evidence. Tokenized webhook intake is implemented; Google Ads, Meta Ads, GA4, HubSpot, and Pipedrive remain explicit non-executable placeholders.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: atlaspipe.access.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Operators who need a controlled data-ingestion path with preview, mapping, validation, deduplication, canonical account/contact records, and synchronization evidence.

Step-by-step

  1. 1Select an entitled workspace and create or choose a tenant-scoped AtlasData source.
  2. 2Upload a UTF-8 CSV file and wait for the bounded durable preview.
  3. 3Review detected columns, inferred types, and the staged upload identifier before importing anything.
  4. 4Map source columns to the supported canonical account and contact fields.
  5. 5Review validation and deduplication behavior, then confirm the staged upload once.
  6. 6Inspect imported, failed, and duplicate counts plus row-level synchronization evidence.
  7. 7Use the source, mapping, sync-log, and data-health views to correct issues and verify the normalized result.
  8. 8For machine intake, create and inspect a tokenized webhook endpoint only inside an authorized workspace.

Verify the result

  • • The preview and confirmed import refer to the same staged upload.
  • • Imported contacts/accounts preserve source and upload provenance without creating unexpected duplicates.
  • • Sync logs show imported, rejected, and duplicate counts that match the confirmed operation.

Current boundaries

  • • The stable internal key and API namespace remain atlaspipe for compatibility.
  • • Google Ads, Meta Ads, GA4, HubSpot, and Pipedrive are explicit non-executable placeholders in the current Beta.
  • • A named connector in the UI does not confirm that the connector is enabled.
  • • Limited Beta status does not represent a production service-level commitment.
betaai_sales_manager

AI Sales Manager

Create and review tenant-scoped leads and campaigns, test encrypted email connections, classify inbound replies, apply suppression, and evaluate controlled send guards. Google Maps discovery remains queued through a separately deployed provider service.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: revenue:read.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

AtlasLoop workspaces that need lead review, campaign coordination, encrypted email-account testing, inbound classification, suppression, and send-policy checks.

Step-by-step

  1. 1Activate the eligible workspace trial, then open AI Sales Manager at /revenue/sales.
  2. 2Create or review leads and campaigns within the selected workspace.
  3. 3Configure an encrypted email account and run its safe connection test before any send evaluation.
  4. 4Use inbound classification and send-policy checks; human approval and suppression rules remain enforced server-side.

Verify the result

  • • The workspace catalog and canonical entitlement endpoint must agree before the product can be opened.
  • • Credential blobs and provider secrets are never returned to the browser.

Current boundaries

  • • No production use, provider coverage, pricing, service level, or autonomous follow-up is claimed.
  • • Controlled send checks do not grant autonomous outbound delivery.