Skip to main content
A successful Forge deployment is an operating change, not only a connection project. Prepare one workflow at a time, make ownership explicit, and expand when the evidence supports it.

​
1. Name the deployment team

Identify:
  • an executive sponsor who can resolve priority and policy decisions;
  • a day-to-day owner for adoption and feedback;
  • a technical owner for systems, mappings, and access;
  • a small pilot group that represents the real workflow;
  • owners for runbooks, skills, and Custom Agents.

​
2. Choose the first customer job

Start with a bounded, frequent workflow such as helpdesk investigation, project scoping, or a recurring account report. Define:
  • the people involved today;
  • the source systems;
  • the starting and ending states;
  • the customer or business outcome;
  • which steps are read, write, review, or background work;
  • conditions that require a person.

​
3. Prepare systems and data

1

Connect the PSA

Verify the organization, accounts, users, tickets, projects, statuses, priorities, boards or queues, and other required reference data.
2

Map operational fields

Confirm Forge’s visible values correspond to the source PSA and test representative writebacks in an approved environment.
3

Connect supporting systems

Add the knowledge, RMM, identity, security, backup, communication, or other systems needed by the first workflow.
4

Map accounts

For account-scoped integrations, verify the Forge account maps to the correct external customer or tenant.
5

Check freshness and health

A successful connection is not enough; confirm syncs, tool access, representative reads, and any allowed writes.

​
4. Configure safety

Create roles, assign feature and system access, narrow tool permissions, configure Availability for each surface, and set interactive Approvals. Test with a pilot user who has the intended role—not only an administrator.

​
5. Train by job

Train helpdesk engineers on tickets and Action Plans, project teams on their own project roles, reviewers on AI Engineer or AI BDR queues, and administrators on system and run monitoring. Use real but safe examples from the pilot workflow.

​
6. Define success signals

Combine product data and user feedback. Useful signals include active users, total Chat threads, Custom Agents, skills or runbooks used, workflow outcomes, time to first useful action, human handoff reasons, and whether users trust the evidence. Avoid setting an automation-rate target before the safe and unsafe boundaries are understood.

​
7. Keep a weekly feedback loop

Review:
  • adoption and outcome trends;
  • representative successful and failed work;
  • missing context or systems;
  • confusing UI or permission boundaries;
  • runbook, skill, or agent changes;
  • the next workflow to enable.
Expand when the current workflow has an owner, stable inputs, tested boundaries, and a visible review path—not simply because the connection is live.