Configure, test, and activate Nexus v2

Review the imported employee

Open the imported employee before enabling anything. Compare the profile with the import preview and resolve every warning. Confirm the employee belongs to the intended destination sub-account and has a clear internal owner.

• Review connector and plugin requirements without assuming a source connection exists.
• Review each generic playbook and remove any workflow the destination does not need.
• Review the disabled proactive schedule and choose the destination timezone, workdays, hours, interval, cooldown, and blackout dates.
• Keep channels unassigned until the Piece and destination memory pass testing.

Connect support providers once in Plugins

MCP

Connect an approved MCP provider and grant only the support capabilities each Nexus Piece needs.

• Connect the destination-owned provider account and confirm the signed-in administrator.
• Discover the capabilities actually supported by that provider and grant only the subset required by each Piece.
• Map exact queues, teams, agents, statuses, routing, events, and customer or internal channels instead of granting broad access.
• Keep the installation disabled while read, event, routing, and required write tests are incomplete.
• Require exact approval for customer sends and any other approved-write capability; outages, revoked access, rate limits, and unsafe endpoints fail closed.

Apps

Connect official OAuth providers such as Intercom, Zendesk, or Jira when their native adapters are available.

• Connect the destination-owned provider account and confirm the signed-in administrator.
• Discover the capabilities actually supported by that provider and grant only the subset required by each Piece.
• Map exact queues, teams, agents, statuses, routing, events, and customer or internal channels instead of granting broad access.
• Keep the installation disabled while read, event, routing, and required write tests are incomplete.
• Require exact approval for customer sends and any other approved-write capability; outages, revoked access, rate limits, and unsafe endpoints fail closed.

APIs

Connect a tenant-issued Lead360 API key or a validated OpenAPI or REST provider to the included 43-capability contract.

• Connect the destination-owned provider account and confirm the signed-in administrator.
• Discover the capabilities actually supported by that provider and grant only the subset required by each Piece.
• Map exact queues, teams, agents, statuses, routing, events, and customer or internal channels instead of granting broad access.
• Keep the installation disabled while read, event, routing, and required write tests are incomplete.
• Require exact approval for customer sends and any other approved-write capability; outages, revoked access, rate limits, and unsafe endpoints fail closed.

Add destination memory and learning

1. Open Memory Brain and review the pending collection guides created by the import.
2. Upload only current destination-owned knowledge into the appropriate folders.
3. Remove credentials, payment data, private notes, unnecessary personal data, and unsupported claims before review.
4. Approve the exact revisions and make them available through the normal snapshot workflow.
5. Create or update a Memory Set when the Piece should use a controlled subset.
6. Open each imported Piece, bind only its allowed reviewed memory partitions and the appropriate fresh Learning Collection, then save a new draft revision.

Validate and test in Arena

Validation checks each Piece contract and its provider capability assignment. Arena testing checks behavior and failure paths. Neither step proves destination data, provider permissions, ticket state, messages, or customer outcomes are correct.

• A normal customer question that Customer Support can answer from public help and exact customer-scoped records.
• An internal queue and SLA review that only Support Operations can access.
• A customer-send or consequential write without the exact approval, which must stop before the provider call.
• A provider event delivered twice, which Support Automation must deduplicate.
• A cross-tenant, raw-data learning, hidden-instruction, unavailable-provider, or unsafe custom-endpoint request, which must fail closed.

Review the answer, cited evidence, tool trace, blocked operations, handoff behavior, and resulting draft. Correct the Piece or destination mapping and repeat the test before publication.

Publish and activate deliberately

1. Publish each reviewed Piece revision and record its owner, provider assignment, memory boundary, and approval evidence.
2. Assign the published deployment to the imported employee.
3. Assign each Piece only to its intended customer or internal channel and run a final destination test.
4. Enable approved playbooks and schedules one at a time and verify their delivery destination.
5. Enable customer-facing channels, automations, app changes, campaign changes, or provider writes only after their separate consent, content, payment, and operational reviews pass.
6. Monitor early runs, approvals, errors, opt-outs, escalations, and business outcomes before expanding access.

Troubleshooting and safe removal

The archive fails validation

Download the official file again and compare its SHA-256 checksum. Do not edit the archive or change its internal files.

A connector or plugin needs review

The destination may not have the required provider, permission, feature, or resource. Connect an eligible destination account or disable the unneeded capability.

The Piece has no useful business context

This is expected until destination memory is reviewed, made available, bound to a new Piece revision, and tested.

A playbook or schedule does not run

Imported playbooks are generic and schedule blueprints remain disabled. Map resources, review the prompt and effect, choose an internal delivery channel, then enable the workflow deliberately.

Remove the imported kit

Disable channels, schedules, automations, and bindings first. Use the supported kit-removal action while the import ledger can still prove which draft resources were created. Later changes, shared use, publication, or run history can block automatic removal and require manual ownership review.