This is a follow-up to I Tried to Package an Agentforce Agent—and Discovered It Is Really a Lifecycle Problem.

The question behind our POC was simple: could we package an Agentforce agent and get it working in another org? We did get an agent-related package installed in a clean org, and the agent worked there. The end-to-end conversation scenarios we tested also worked as expected. That was a good result. It also left us with a harder question: what evidence would we need before calling the agent ready to release more broadly?

I’m calling that missing piece an Agent Release Contract: a versioned, machine-checkable record of the agent, its dependencies, the subscriber-org setup it needs, and the checks it must pass before release. We have not built that contract yet. The V67 POC is what made the need for one clear. Here, V67 means Salesforce API version 67.0—not our package’s product version.

What was in the project

The agent definition, PK4_Employee_Agent.agent, is stored as an AiAuthoringBundle. The project also has the supporting Apex actions, custom metadata, object definitions, permission set, bot metadata, and planner bundle.

Keeping these files in source control gives us a history we can review. But a file appearing in the repository is not, by itself, proof that it made it into the package version installed by a subscriber. That distinction shaped the rest of the POC.

The project tree shows where the source artifacts live. It’s useful context, but it isn’t an install record.

The API versions didn’t tell the whole story

While reviewing the project, we found three API-version settings:

sfdx-project.json                 sourceApiVersion: 67.0
manifest/agentforce-deploy.xml    <version>67.0</version>
manifest/package.xml              <version>63.0</version>

The focused Agentforce manifest lists the authoring bundle, custom metadata type definitions, and selected Apex classes. It doesn’t list the Bot, BotVersion, or planner metadata that are also in the source tree. The general package manifest lists other metadata, including custom metadata records and the runtime permission set.

At first glance, those values can look like competing answers to the same question. They aren’t. The project setting and each manifest apply to their respective source, retrieve, or deploy workflows. Package-version creation uses the configured package directory; the deployment manifest is not an inventory of what the package contains.

The repository also records aliases for package versions 2.8.0-1, 2.8.0-3, 2.8.0-4 and 2.9.0-4. Those records show that versions were created, but they don’t show which of those versions was installed in the clean-org test or what metadata it received; that requires the install record and a post-install metadata check. The uninstall test described later used a separate Beta 2GP package version, 2.9.0.4. These are different version records, not alternate spellings of the same version.

That became the most useful lesson from the POC: the project API version, a manifest’s API version, and the package contents are related, but none is a substitute for checking the others.

What we actually proved

Here’s how I’d describe the evidence today:

One successful install in a clean org is valuable POC evidence. It shows the package installed and the agent worked in the org we tested; it doesn’t establish repeatability in another clean org or confirm the complete installed metadata set. We should record those separately.

Checks we want before a wider release

For the next release run, I’d want to:

1. Record the exact package version installed in the clean org, along with the target-org type, install log, and post-install steps. Capture a metadata inventory, then repeat the install in another clean org to establish repeatability.

2. Check that the authoring bundle, matching Bot and BotVersion, planner bundle, actions, and supporting metadata are all present for that version.

3. Document the subscriber setup: which user runs the agent, what access it needs, and which settings must be configured in the target org.

4. Re-run and record end-to-end agent conversation tests against the installed package. The scenarios we tested in this POC worked as expected; for the next release, document the prompts and expected results and add broader coverage. Keep the direct action tests too; they cover a different layer.

5. Investigate whether the remaining planner-related dependencies can be removed, then repeat the uninstall test in a disposable org and record the metadata state and exact result.

We should also name a previously approved version and rehearse restoring it in a non-production org. That gives us a real rollback target rather than an assumption that we can always move back safely.

We could not uninstall the Beta 2GP package

Uninstall is the part we could not complete. In our development/test org, Beta 2GP package pk4_agentforce version 2.9.0.4 could not be uninstalled.

We removed the Agentforce bot PK4_Employee_Agent_Bot, but a planner definition, PK4_Employee_Agent_v1, remained after its planner bundle was no longer present. Related planner-function and plugin records also appeared to remain linked to the managed agent metadata.

We tried to remove the remaining planner definition through the Tooling API. The org returned: INVALID_CROSS_REFERENCE_KEY: In field: members - no GenAiPlannerBundle named PK4_Employee_Agent_v1 found. Attempts to delete the associated planner-function dependency records returned READONLY. We also could not remove the remaining managed records through Setup, Metadata/Tooling API, or the CLI. The package uninstall therefore remained blocked.

That is the result we observed for this Beta package in our development/test org; it does not establish that every Agentforce or 2GP package has the same limitation. We have not yet verified a cleanup path. Our next step is to investigate the remaining planner-related dependencies and repeat the uninstall test in a disposable org.

Salesforce documents deleting an eligible inactive agent or version in Agentforce Studio separately (documentation). Deleting an agent is not the same as uninstalling the package and its metadata, which is the issue we hit here.

What the contract could look like

I don’t want this to become just another checklist in a document. The useful version would be a small file that a release pipeline could check: Is the exact package version recorded? Are its dependencies listed? Are the subscriber setup steps clear? Did the required tests pass?

For example, the first draft might look something like this:

contractVersion: "0.1" # proposed example; not implemented in this POC
agent: "PK4_Employee_Agent"
apiVersion: "67.0"
packageVersion: "<record the exact version tested>"
dependencies:
  - "authoring bundle"
  - "matching Bot and BotVersion"
  - "planner bundle"
  - "actions and supporting metadata"
subscriberSetup:
  - "agent runtime user"
  - "required object and field access"
checks:
  install: "passed"
  cleanOrgInstall: "passed in one clean org; repeatability not tested"
  conversationTests: "passed for scenarios tested"
  uninstall: "blocked in tested org by remaining planner/plugin metadata"
rollbackTarget: "<previously approved version>"

This is only a sketch, not a file our package currently enforces or a Salesforce feature. The exact fields and allowed status values would need to be agreed and validated. The point is to make the release assumptions visible—and eventually testable—before the package reaches another org.

Next: the V68 POC

Salesforce’s V68 Agentforce metadata guide describes a newer pattern. We haven’t tried it in this POC. In the next post, we’ll package the same agent with V68 and compare what changed against this V67 baseline.

References

• Salesforce, Agentforce Metadata Types in V67 and Earlier

• Salesforce, Move an Agent to a New Org

• Salesforce, Publish an Authoring Bundle to Your Org

How can one chat entry point let an employee choose the Salesforce agent they need, complete a task, and return to select another capability?

The answer starts with an explicit agent chooser. The employee selects an available agent, then has a direct conversation through that capability. Later, they can return to the chooser from the same chat tool.

This working POC brings that experience to Google Chat and Microsoft Teams. The recordings show live conversations, a reviewed time-entry request, confirmation, and a business result. The Teams walkthrough also opens Salesforce to verify the saved entry.

This article follows that build through screenshots from the demonstrations, then explains the design decisions another builder can apply. The architecture describes responsibilities; the evidence below shows the working interaction.

Start with one business task, then add agent choice

The example is familiar: an employee needs to find assigned work and record three hours against a task.

The conversation has two kinds of request. Asking about projects or tasks retrieves context. Recording time changes business data. Separating those two helps identify where the employee needs a review step.

Then introduce agent choice. A single channel can expose several available capabilities without making the employee learn a new chat interface for each one.

The scope still comes from the selected agent. The chooser answers “Which capability am I using?” The conversation answers “What do I want that capability to do?”

The working POC: from a chat request to a Salesforce record

In the Teams demonstration, the employee asks to record three hours against TT Demo - Configure Time Tracking for September 30, under TT Demo Project. The agent presents the proposed fields, asks whether to proceed, and reports the result after the employee replies “Yes.” The walkthrough then checks the Salesforce list for the matching entry.

This is the evidence that makes the example a working POC. The time-entry path is demonstrated through to a saved record in Teams. The Google Chat footage also demonstrates the selection interface and the return to that interface after the workflow. It does not show a second agent executing a different business action.

A small architecture with clear responsibilities

This functional boundary is useful even before choosing infrastructure. Define what each part is responsible for, then validate the complete interaction. The diagram does not prescribe an API, hosting provider, or programming language.

Lesson 1: connecting an account and choosing an agent are different steps

The Google Chat demonstration shows the employee connecting Salesforce, returning to chat, and choosing an agent. Those steps serve different purposes.

Connecting establishes the Salesforce environment and authorization used by the experience. Choosing identifies the agent the employee wants to talk to within that environment.

For a similar build, make both states visible. A connected account should not leave the employee guessing which agent is active. An agent choice should not imply access that the user has not been granted.

Before testing, identify the target Salesforce environment, the chat account, the intended agent, the business action, and the demo records. Check the required connection setup and permissions for your implementation. A connection-success message is the beginning of the test, rather than proof that every action can execute.

Lesson 2: make agent switching an explicit interaction

Both recordings show the agent chooser. Google Chat shows more than one choice and returns to the chooser after the time-entry workflow. Teams shows the PK4 Employee Agent available in its demonstration environment.

Build evidence 1 — Teams, 2:00: the employee sends “Choose agent,” and the selection card displays PK4 Employee Agent. The card explains that Salesforce verifies access. This frame demonstrates the chooser in the Teams environment.

The Google Chat recording at 3:05 also shows the user returning to the chooser after the time-entry workflow. Neither chooser frame demonstrates a second agent executing a different business action.

The employee-facing sequence is simple:

1. Send “Choose agent.”

2. Review the available choices.

3. Select the intended agent.

4. Ask a question relevant to that capability.

That makes switching discoverable. It also gives the employee a useful boundary: a new selection means a different capability may be handling the next request.

For a build with two working agents, validate the switch itself. Ask the first agent a question within its scope, select the second agent, and ask a question unique to that second capability. Check the active agent identity and returned action evidence. A chooser with two buttons proves that choices are displayed; responses from both capabilities provide stronger switching evidence.

The supplied recordings do not establish how conversation history transfers between agents. Decide and test that behavior explicitly. Document whether a selection starts fresh or carries context, and explain it to the employee. In particular, a pending write proposal from one agent should not silently become authorization for another agent's action.

Lesson 3: resolve business fields before requesting confirmation

The Teams demonstration turns a request for three hours of work into a proposed entry with a project, task, work date and duration. The employee sees those fields before agreeing to proceed.

Build evidence 2 — Teams, approximately 0:59: the conversation shows the proposed fields, the employee's “Yes,” and the reported recording result. Watch the linked segment to read the fields at full video resolution.

That is a reusable interaction design:

Use readable names in the proposal. Keep record identifiers available for the action and diagnostics, but avoid making employees interpret IDs to decide whether the entry is correct.

The Google Chat recording illustrates why name consistency matters: its proposal and completion message use different project wording. Check the actual project/task relationship before calling the result correct. This is a concrete validation lesson, not a confirmed diagnosis of the implementation.

Lesson 4: employee confirmation and manager approval are separate

The Teams chat asks the employee whether to proceed. The resulting Salesforce list shows a pending approval status.

The employee has confirmed creation of the entry. That does not mean a manager has approved the timesheet.

Describe those stages precisely in the conversation. “Recorded, pending approval” tells the employee more than a broad statement that everything is complete.

For implementation, enforce authorization and business validation in the action layer. The visible confirmation prompt alone cannot prove backend enforcement. Validate the exact proposal again before writing, and define how changed inputs, expired proposals and repeated requests are handled.

Lesson 5: verify the record, then evaluate the experience

The Teams walkthrough opens Salesforce and shows a row matching the demonstrated task, September 30 work date and three-hour duration. That connects the chat action to a visible business result.

Build evidence 3 — Teams, 1:10: the Salesforce list provides the record check after the chat action. Compare the task, project, September 30 work date and three-hour duration with the proposal; the approval status is still pending. Open the video for a closer view of the row.

Use that same evidence pattern when validating another workflow. Compare the saved fields with the reviewed proposal. Check the work date separately from the record's creation date; a retrospective entry can legitimately have different dates.

A validation guide another builder can use

Start in an appropriate test environment with clearly identified demo data. Prepare the following checks before recording the happy path:

These are recommended validation cases, not a claim that the recordings demonstrate every one. Record expected and actual behavior so another builder can understand both the successful path and its boundaries.

What this pattern solves

The implementation makes Salesforce agent capabilities reachable through Google Chat and Teams. The employee can retrieve work context, review a time-entry request, and return to the chooser without leaving the chat tool.

The intended benefit is easier access to business workflows and fewer application changes. The demonstrations establish the interaction and, in Teams, a matching record. They do not measure productivity gains.

To evaluate impact, run the same task manually and through chat using equivalent records. Compare correctness, elapsed time and corrections required. That gives the next article a measured outcome rather than an estimated percentage.

Apply these lessons to the next build

Make the active capability visible. Treat agent selection as a deliberate conversation boundary. Review business fields before writing. Distinguish creation from downstream approval. Verify the saved record.

Those decisions make a chat integration easier to understand and test. They also give another builder a starting point for a different workflow—across different infrastructure and business objects.

Watch the examples: Google Chat walkthrough and Microsoft Teams walkthrough.

When a user switches agents in your implementation, what happens to their conversation context and pending actions?

That last step can feel small, but it asks the employee to change applications, find the right record, and reconstruct the context of work they have just completed.

We wanted to make that handoff easier.

With PK4 Agentforce for Google Chat and Microsoft Teams, we brought access to Salesforce agents into the tools employees already use for conversations. Our demonstrations follow a practical workflow: ask about assigned work, describe the time spent, review the proposed entry, and confirm it.

The most useful moment is the transition from a conversation to a business action: the employee sees what will be recorded and decides whether to proceed.

There is another important part of the experience: the employee can switch between available Salesforce agents without leaving the chat tool. The channel provides a familiar place to work, while the agent chooser lets the employee select the business capability they need.

What this solves

The problem starts with a split workflow: employees discuss work in chat, while project information and time entries live in Salesforce. Our implementation brings access to the selected Salesforce agent into the conversation.

The demonstrated result is a reviewed time-entry request, with a matching Salesforce row visible in the Teams walkthrough. Reduced switching between applications is the intended benefit; we have not measured productivity or time savings yet.

A simple architecture: chat, bridge, selected agent, records

Functional overview of the demonstrated experience. The diagram shows responsibilities and conversation flow rather than backend deployment details.

The employee uses Google Chat or Microsoft Teams. The PK4 bridge connects that chat experience to Salesforce, offers agent selection, carries requests, and returns responses. The selected Agentforce agent supplies the conversation and business actions that work with Salesforce records.

This is a direct conversation with the agent the employee selected. When they need a different capability, they return to the chooser and select another available agent.

Agent availability depends on the connected Salesforce environment and user access. The recordings do not establish the bridge's programming language, hosting provider, or exact API implementation, so those details are outside this diagram.

Start with the employee's task

For this implementation, the scenario was project work and time tracking. An employee needs answers to familiar questions:

• Which projects am I assigned to?

• What tasks should I look at?

• How do I record the time I spent on one of them?

The aim was to make those questions actionable within Google Chat or Teams while keeping the Salesforce agent and its business capabilities central to the experience.

A chat channel becomes useful when it carries the workflow far enough to complete an operation. For time tracking, that means finding the relevant work, resolving the intended entry, and giving the employee a chance to review it.

Google Chat: connect, choose an agent, continue the conversation

The Google Chat walkthrough starts with a connection card. The employee chooses the appropriate Salesforce environment, identifies the Google account being linked, and completes Salesforce authorization.

These are separate steps with different purposes. Google sign-in identifies the chat user linking the account. Salesforce authorization connects that user to the Salesforce environment. The walkthrough explains that Salesforce permissions govern access; the video itself does not constitute a full permissions audit.

Once connected, the employee chooses an available Salesforce agent. In this example, that is the PK4 Employee Agent.

The conversation then moves into everyday work. A project question returns a list of assignments in the Google Chat thread. A follow-up asks about today's tasks. The agent reports that no active tasks are due today or tomorrow, and the employee broadens the question to work during the week.

That is a useful part of the demonstration. An empty result leads to another question rather than ending the interaction. The employee can refine the request in the same thread.

The bridge also acknowledges that a request is being processed. That acknowledgement helps the employee understand what is happening while the answer is prepared. The recording explicitly says that waiting periods have been shortened, so its runtime should not be treated as a response-time benchmark.

The important step: review before recording time

Later in the Google Chat demo, the employee requests a three-hour time entry for restaurant systems installation work on September 29.

The agent turns that request into a proposed entry and presents the fields the employee needs to check:

Only after the employee confirms does the conversation report that the three hours have been logged.

One detail deserves attention: the Google Chat footage uses different project wording in the proposal and the completion response. The task, date, and hours are visible, but the project association should be checked against the saved record. That is exactly why the review step matters—and why a clean final demonstration should show consistent names throughout.

For this Google Chat recording, the visible evidence establishes the proposal, the employee's confirmation, and the agent's reported completion. A subsequent Salesforce screen appears, but it does not clearly display the matching time-entry record. The Teams recording provides the clearer record verification.

Microsoft Teams: follow the action into Salesforce

The Microsoft Teams walkthrough shows the same kind of employee experience in another channel.

The employee asks about tasks, expands the date range, and requests three hours for configuring time tracking on September 30. The agent presents the project, task, work date, and hours, then asks whether to proceed.

After the employee confirms, the conversation reports that the entry has been recorded.

The presenter then opens Salesforce. The time-entry list visibly contains a matching row for the demonstrated project and task, with a three-hour duration and the September 30 work date. The creation date is later than the work date, illustrating an important distinction: the date an employee records time is not necessarily the date they performed the work.

This is the strongest evidence in the two recordings. It connects the conversation to a visible Salesforce result.

The chat uses the word “approval” when asking the employee to proceed. Here, that step is employee confirmation before creation. The Salesforce list still shows a pending approval status, so the demonstration should not be described as a completed manager-approval workflow.

Two channels, one workflow pattern

The recordings show a common interaction pattern across Google Chat and Teams:

The Teams video extends that last step with visible Salesforce record verification.

At a functional level, the channel connects the employee's request to a Salesforce agent and returns its response. The selected agent supplies the business experience. That distinction helps keep the article focused: Google Chat and Teams provide access to the conversation; the Salesforce agent provides the project and time-tracking capability.

The videos do not reveal enough backend detail to establish the exact API, hosting architecture, token handling, or whether each action uses Apex or Flow. Those implementation details need source or configuration evidence before they can become a reproducible technical tutorial.

Switch agents without leaving Google Chat or Teams

Agent switching is a core feature of this experience. The employee can return to the agent chooser from the same chat tool instead of opening another application to find the next capability.

The interaction is straightforward:

1. Send “Choose agent.”

2. Review the available Salesforce agent choices.

3. Select the agent you want to use.

4. Continue with questions and actions relevant to that agent.

Both recordings show an agent-selection interface. Google Chat demonstrates returning to the chooser after the time-entry workflow, with more than one choice visible. Teams shows the chooser with the PK4 Employee Agent available in its demonstrated environment. Google Chat also shows the Salesforce disconnect flow.

This matters because the channel experience can provide an entry point to more than one business capability. The demonstration uses the PK4 Employee Agent; the available choices depend on the connected environment and user access.

The Teams narration discusses other possible agents, such as inventory or opportunity management. Those are extension possibilities in this walkthrough, rather than executed scenarios. The demonstrated behavior is selecting an agent and using its capability. Coordinated execution between several specialist agents would require separate evidence.

For builders, the reusable idea is to keep agent choice visible and understandable. Employees need to know which capability they are asking to act on their behalf. One chat entry point can offer a choice of available agents, with a direct conversation through the selected capability.

The recordings establish the chooser experience; they do not establish whether conversation history transfers between agents. Each selection should make the active agent and its scope clear.

What we learned from the demonstrations

Review the business fields, not just the sentence. A fluent response can still contain a wrong project association. Project, task, work date, and duration need to be understandable before the employee confirms.

Show the record after the action. A completion message is useful feedback. A matching Salesforce row gives readers much stronger evidence of the result. The Teams walkthrough does this well.

Make empty results useful. Both conversations encounter a question with no tasks due in the requested period. The next step is to clarify or broaden the request. The experience benefits from that ordinary interaction as much as from a successful write.

Keep the response readable in chat. Long task lists, raw record identifiers, and repeated summaries make it harder to find the next decision. The recordings suggest a clear refinement: lead with a short business summary and put additional detail behind a follow-up where the channel supports it.

Separate confirmation from authorization. The videos show the employee agreeing to a proposed entry. Production enforcement also needs to validate access, inputs, and the exact operation on the server. Duplicate protection, expired connections, cancellations, and restricted-user behavior deserve their own tests; they are not established by a successful demo.

The value—and what we still need to measure

The demonstrated value is concrete: an employee can request a time entry through a chat conversation, review it, and receive a completion response. In Teams, the footage also shows the corresponding Salesforce record.

That makes reduced application switching and easier time capture credible benefits to investigate. The videos do not measure time saved, adoption, or productivity improvement, so I would not attach a percentage to them.

A useful next measurement is simple: ask employees to complete the same lookup-and-time-entry task manually and through chat. Compare correctness, elapsed time, and the number of corrections required. Then report what was actually observed.

Bringing the action closer to the work

This implementation began with a practical question: can an employee use a Salesforce agent from the chat tool they already work in?

The two recordings show that experience through project questions and time entry. The Teams demonstration adds a visible Salesforce result. Together, they offer a useful pattern for other builders: connect the user, expose the appropriate agent, preserve the conversation, present the intended action clearly, and verify its outcome.

For me, that is the lesson worth sharing. A familiar channel can make a business capability easier to reach. Careful review and visible results make that experience easier to trust.

Which Salesforce workflow would your employees benefit from completing directly in Google Chat or Microsoft Teams?

Watch the demonstrations: Agentforce for Google Chat · PK4 Agentforce for Teams.

This article describes the behavior visible in the supplied demonstrations. The video review did not independently execute the applications or audit their backend security controls.

“Show me Acme’s open opportunities.”

It sounds straightforward. But imagine your Salesforce org contains Acme Manufacturing and Acme Services. Both have open opportunities.

An agent can run a valid query, receive real Salesforce records, and still answer about the wrong customer.

This article shows how an agent can identify the correct Account, retrieve its open opportunities, and explain any limits on the results.

We’ll use SOQL and SOSL behind two proposed Agentforce actions. This is an architectural walkthrough with synthetic examples; the snippets and conversation are illustrative, not results from a deployed agent.

Identify the Account before retrieving opportunities

“Acme” may match several Account records. The agent needs to identify which Account the user means before retrieving opportunities.

Separate the request into two decisions:

1. Resolve identity: Which account does the user mean?

2. Retrieve facts: Which open opportunities belong to that account?

The first step may require search and clarification. The second needs a precise record ID and a defined query.

SOQL retrieves records from specified objects using filters and relationships. SOSL performs text search against Salesforce’s search index and can return matches across multiple objects. Salesforce’s SOQL and SOSL guide explains when each is appropriate.

This example searches only Account records because the next query filters opportunities by Account ID. SOSL can search a single object; it does not have to search Accounts, Contacts, and Leads together. Choose SOQL or SOSL according to the matching behavior your application needs.

Action 1: search for matching Accounts

The first proposed custom action, Search Accounts by Name, accepts a name such as “Acme” and returns matching Account records that the running user can access. This is a descriptive name for the custom action in this example, not a standard Salesforce action.

The results contain Account IDs, names, and an accessible city field so the user can distinguish similar Accounts. Each result is a possible match until the intended Account is confirmed. The agent uses the selected Account ID to retrieve opportunities in the second action.

The following illustrative SOSL search returns Account records whose name fields match the search term:

FIND {Acme*} IN NAME FIELDS
RETURNING Account(Id, Name, BillingCity LIMIT 6)

The literal term makes the syntax readable. An Apex implementation should validate and bind search input rather than concatenate the conversation into executable query text. The standalone expression above also needs an implementation that explicitly enforces the intended access mode.

The search retrieves up to six Account records, while the agent displays at most five. If a sixth record is returned, the agent asks the user to narrow the search. The extra record detects that the display limit was exceeded.

Show the city only if the running user has permission to view it. The city helps distinguish Accounts with similar names. Ask for further clarification if the displayed details still do not identify the intended Account.

Illustrative design: resolve the account identity before querying its opportunities.

An illustrative exchange:

User: Show me Acme’s open opportunities.

Agent: I found Acme Manufacturing in Pune and Acme Services in Bengaluru. Which account do you mean?

User: Acme Manufacturing in Pune.

Pass the selected Account ID to the second action. Keep this ID throughout the workflow so the opportunity query uses the Account the user selected.

If no candidate is returned, ask for a more specific name or trusted identifier. Say “I couldn’t find a matching account,” rather than claiming the account does not exist.

A real platform example: Select Record

Salesforce’s standard Select Record action illustrates the same clarification principle: its description asks the agent to prompt the user when several records match. The configuration accepts record IDs and returns associated records.

Actual screenshot from a Developer Edition org. This is a standard Salesforce action, not the custom SOSL action proposed here. It demonstrates configuration, not a successful execution of this article’s demo.

Action 2: retrieve open opportunities for the selected Account

The second proposed custom action, Get Open Opportunities, accepts the confirmed Account ID and returns that Account’s accessible open Opportunity records.

The two actions retrieve different records: Search Accounts by Name returns Accounts for selection; Get Open Opportunities returns Opportunities linked to the selected Account through Opportunity.AccountId.

Before querying opportunities, validate that the input is an Account ID, check access to the Account, and reject invalid or unauthorized requests.

This Apex fragment assumes those checks have succeeded:

// accountId: validated, authorized Account ID.
// Retrieve one extra row to detect a truncated display.
List<Opportunity> rows = [
    SELECT Id, Name, StageName, CloseDate
    FROM Opportunity
    WHERE AccountId = :accountId
      AND IsClosed = false
    WITH USER_MODE
    ORDER BY CloseDate ASC, Id ASC
    LIMIT 11
];

Boolean hasMore = rows.size() > 10;
if (hasMore) {
    rows.remove(rows.size() - 1);
}

The returned list contains at most ten rows. hasMore tells the agent whether the query found an additional accessible match at retrieval time. It does not reveal the total number of opportunities.

Illustrative example: an extra accessible row signals more matches, not the total count.

The secondary Id ordering makes ties in close date deterministic. The row cap bounds the response; it does not, by itself, establish that the query is selective or efficient.

This query returns opportunity names, stages, and close dates. To answer a question about pipeline value, use a separate calculation that defines which records and currencies it includes.

The answer should change with the result:

Treating the last two cases differently prevents a technical failure from becoming a false business conclusion.

Return records with a clear status and result limit

Agentforce can expose Apex methods annotated with @InvocableMethod as custom actions. See Salesforce’s Apex action documentation and configuration workshop.

For this design, use an explicit output contract:

Use hasMore only when retrieval succeeds; failure cannot establish whether further matches exist. These names are proposed application fields, not built-in Agentforce outputs.

A useful description for the opportunity action would be:

Retrieve up to ten open opportunities for a confirmed, authorized Account ID, ordered by close date. Use only after account identity is resolved. Explain when additional matches exist. Do not describe the returned subset as the account’s total pipeline.

Implement validation, permissions, and limits in code. Action descriptions help the agent select and explain behavior; they do not replace those controls.

The retrieval flow

1. Search: use Search Accounts by Name to retrieve matching, accessible Account records.

2. Clarify: if identity is unresolved, ask the user to choose or narrow the search.

3. Validate: check the selected Account ID and access.

4. Query: use Get Open Opportunities to retrieve open Opportunity records linked to the selected Account ID.

5. Explain: return the records, status, and scope; disclose truncation.

Proposed custom-action flow. Validation and retrieval failures should produce controlled responses.

Permissions depend on who executes the action

The query explicitly uses WITH USER_MODE. Salesforce recommends explicit access modes to make intent clear across API versions. with sharing addresses record sharing; it is not a substitute for object and field permissions. See Secure Apex Classes.

For this walkthrough, assume an authenticated employee-facing use case and verify the action’s actual running identity in your configuration.

A customer-facing agent may require additional identity and entitlement checks. The running user’s Salesforce access alone does not prove that a conversation participant is entitled to a particular customer’s data.

Test permissions on both actions. A secure opportunity query does not repair an account search that already disclosed unauthorized candidate details.

Test the workflow with synthetic records

Use synthetic records in a development org. Create two similarly named accounts, one with twelve open opportunities and the other with none. Add a closed opportunity to verify the filter. Use valid stages from your org.

Then test the behavior that matters:

These are acceptance criteria, not claimed results. Record the API version, running identity, inputs, outputs, and observed behavior when implementing the example.

Confirm the Account, then retrieve its opportunities

Start by identifying the Account the user means. Search for matching Accounts, clarify ambiguous results, and pass the confirmed Account ID to the opportunity query.

SOQL and SOSL help retrieve records. A dependable Agentforce action also preserves the selected identity, enforces access, and tells the agent when the answer is incomplete.

Verify three behaviors before using this workflow: the agent selects the intended Account, retrieves only authorized records, and explains when more results are available.

Yet when the user tried to message my Agentforce Employee Agent, Slack displayed:

“You don’t have permission to message this app.”

I began investigating licenses and permissions. What eventually resolved the issue was revisiting the sequence used to configure the Slack connection, commit the agent, activate it, and refresh Slack.

This case changed one question in my troubleshooting checklist: alongside checking who has access, check which configuration reached the active agent.

The setup and the symptom

This case involved an Agentforce Employee Agent, a Slack connection configured in Agentforce Builder, and testing through Slack. The workflow I used included Draft, commit, and activation.

Before changing anything, I reviewed the setup:

Slack also displayed the agent’s permissions as “Managed in Salesforce.” Together with the error, that made Salesforce access settings a natural starting point.

Where my initial investigation led

I investigated Agentforce Platform User licensing, Unified Employee or Employee Agent entitlement, user permissions, and possible Developer Edition limitations.

Those checks did not lead to the resolution.

The useful shift was to examine when the Slack connection was configured in relation to commit and activation. I had checked that the connection existed; I needed to revisit the workflow that put it into use.

The sequence that worked in my case

I followed these steps:

1. Deactivate the agent if it is already active. This was my starting point before revisiting the configuration.

2. Open the agent in Draft. Make the connection changes in the editable draft.

3. Configure the Slack connection. Complete this while the agent is in Draft.

4. Save the changes.

5. Commit the agent version containing the updated configuration.

6. Activate that version.

7. Restart the Slack desktop application, or perform a hard refresh when using Slack in a browser.

8. Retest with the affected user. Confirm that the user can message the agent and receive a response.

The sequence was:

Draft → Configure Slack → Save → Commit → Activate
                                              ↓
                                  Refresh Slack → Retest

After completing the sequence, the Employee Agent became available in Slack and the user could interact with it.

No additional license or permission changes were needed to resolve this case.

How this relates to the official workflow

Slack’s official Agentforce setup guide describes adding the Slack connection in Agentforce Builder, committing the version, and then activating the agent. It provides separate instructions for the legacy builder, so use the workflow that matches your interface.

Salesforce’s Commit an Agent Version documentation explains that committing creates a snapshot and prepares the agent for use outside Builder. Further edits to a committed version require a new draft.

These references support the connection → commit → activate order. They do not establish that my exact Slack error always has this cause, or that deactivation and a client restart are universally required. Those steps describe the recovery sequence I used.

The result—and the limits of the conclusion

I changed the configuration sequence and refreshed Slack before retesting. I did not isolate each step independently.

My conclusion is therefore specific:

Reconfiguring the Slack connection in Draft, saving, committing, activating, and refreshing Slack resolved the issue in my environment. I did not isolate which individual step caused the change.

The result is useful without turning it into a universal diagnosis. Salesforce’s connection guidance also makes clear that an agent’s Slack interactions respect the user’s Salesforce licenses, permissions, and access controls. Those checks still matter.

The visual recap

An illustrated recap of this case, rather than a screenshot of the tested system. Its licensing and permissions conclusions apply to this incident.

The checklist I would use next time

Next time, I would record the result after each change. That would help distinguish a configuration correction from a client refresh effect.

The learning I am taking forward

In my earlier article, I Tried to Package an Agentforce Agent—and Discovered It Is Really a Lifecycle Problem, I explored how delivering an agent involves more than installing its components.

This experience brought that lifecycle lesson into integration troubleshooting.

My checklist now includes one more question: did the connection configuration reach the version I activated? Sharing that small detail may help another builder investigate the same confusing error.

That is the #AgentblazerEffect I want to contribute to: practical experiences, documented clearly enough for someone else to learn from.

Have you encountered a similar error? What helped you distinguish an access issue from a configuration or activation issue?

This firsthand case study describes the workflow and outcome in my environment. It is not a universal fix for Slack permission errors.

That difference became clear while I was experimenting with how an ISV could distribute Agentforce capabilities through a second-generation managed package (2GP).

My original expectation was simple:

Install managed package
        ↓
Working agent

What I discovered looked more like this:

Install managed package
        ↓
Install stable capabilities
        ↓
Configure subscriber environment
        ↓
Build customer-specific agent
        ↓
Compile and publish
        ↓
Test and activate
        ↓
Working agent

That small-looking difference changed how I think about Agentforce distribution.

The package installs the capabilities. A separate provisioning lifecycle assembles those capabilities into a customer-specific agent.

Once I understood that, the challenge stopped looking like a packaging problem. It became an agent lifecycle architecture problem.

Why I started exploring this

Imagine that you are an ISV shipping a Salesforce application. Your package already contains the components an agent needs: Apex actions, Flows, permission sets, configuration and business logic.

The natural next question is: can the package also deliver the agent, so that the customer installs it, clicks one button and starts using it?

That was the experience I wanted:

Customer installs package
        ↓
Opens Agent Installer
        ↓
Reviews configuration
        ↓
Clicks Provision Agent
        ↓
Agent is ready

I built a proof of concept around that idea using a namespaced package called PK4 Agent Installer POC, with the namespace pk4_agentforce.

The stable package layer contained a global invocable Apex action, an Apex test and a permission set. The business capability packaged successfully. But installing those components did not automatically produce a configured, compiled and published customer agent.

That is where the interesting part began.

Discovery 1: package installation is not agent publication

The managed package keeps the reusable business logic. The customer org handles the agent-specific setup, instructions, and configuration.

This gives us a clean split: the package keeps the core capability, while each customer can have its own agent instructions, permissions, and configuration.

What I actually validated

I kept the business action simple so I could isolate and test the packaging boundary.

global with sharing class PK4ProjectHealthAction {
    global class Request {
        @InvocableVariable(required=true)
        global String projectName;
    }

    global class Result {
        @InvocableVariable global String projectName;
        @InvocableVariable global String healthStatus;
        @InvocableVariable global String summary;
    }

    @InvocableMethod(label='PK4 Check Project Health')
    global static List<Result> checkHealth(List<Request> requests) {
        List<Result> results = new List<Result>();

        for (Request request : requests) {
            Result result = new Result();
            result.projectName = request.projectName;
            result.healthStatus = 'GREEN';
            result.summary = request.projectName
                + ' is healthy. Executed through the packaged action.';
            results.add(result);
        }

        return results;
    }
}

After installing the package, the subscriber-side Agent Script can reference the packaged capability through its namespace:

actions:
  get_project_health:
    label: "PK4 Check Project Health"
    description: "Returns project health for a named project."
    target: "apex://pk4_agentforce__PK4ProjectHealthAction"

The namespace creates a clean ownership boundary. The package owns the business implementation; the subscriber agent simply references it.

The POC validated the package/action boundary. The upgrade, retry, and rollback model below is the production architecture I derived from that experiment; those scenarios still require full validation.

Discovery 2: the LWC should be the control plane

My next thought was: perhaps the Agent Installer LWC can create everything.

That also needed refinement.

The LWC should handle the admin experience: review the setup, choose the user the agent will run as, check prerequisites, start the process, and show progress. The actual deployment should happen in the background.

The better separation is:

Administrator
      ↓
Agent Installer LWC          captures intent and shows status
      ↓
Apex orchestrator            owns workflow and subscriber setup
      ↓
Publishing implementation    compiles, publishes, polls and retries
      ↓
Agentforce

The LWC is the control plane: it starts provisioning and shows progress. Asynchronous orchestration executes the lifecycle.

Architect's takeaway: the UI captures administrator intent; orchestration owns execution.

Discovery 3: publishing is more than inserting metadata

Salesforce represents an editable Agent Script blueprint through the AiAuthoringBundle metadata type. The bundle includes the .agent script and its metadata definition.

Publishing that bundle is not equivalent to inserting a record. The documented Agentforce DX workflow validates and compiles Agent Script, creates or updates related agent metadata and deploys the authoring bundle.

The lifecycle is therefore closer to:

Agent Script → validate → compile → publish → test → activate

So the agent setup process has to handle this full publishing lifecycle safely.

Salesforce documents the authoring-bundle model in Agent Metadata and the publication command in the sf agent publish authoring-bundle reference.

Two production directions emerged

Once I separated packaging from publishing, I saw two possible architectures.

Architecture A: hybrid provisioning

In the hybrid approach, Salesforce handles the customer setup experience and the initial checks. A small external service handles the longer-running work such as compiling, publishing, checking status, and retrying failures.

Subscriber administrator
          ↓
Agent Installer LWC
          ↓
Managed Apex orchestrator
  • preflight
  • runtime user
  • permissions
  • configuration
  • rendered template
  • provisioning job
          ↓ authenticated request
Restricted publishing service
  • validate tenant and package
  • compile and publish
  • poll and retry
  • return structured result
          ↓
Published subscriber agent

The external service handles long-running compilation, deployment polling, retries, and centralized monitoring. Because it accesses subscriber orgs, it also becomes part of the security boundary.

Use explicit, revocable authorization. Validate the subscriber and installed package. Accept only approved templates, and never log usernames, passwords, or access tokens.

The ideal request is logical:

Provision template ProjectAgent
Version 1.3
For subscriber org X
Using configuration hash Y

It should never mean: “execute this arbitrary payload.”

Architecture B: Salesforce-only provisioning

The alternative keeps the execution inside the subscriber org:

Agent Installer LWC
        ↓
Managed Apex orchestrator
        ↓
Queueable Apex
        ↓
Named Credential
        ↓
Supported Salesforce API
        ↓
Poll, publish, assign and activate

This keeps customer configuration inside Salesforce and removes the need for an ISV-hosted publishing service.

But “Salesforce-only” does not mean “no integration.” Apex cannot execute Salesforce CLI commands. The design still needs a documented, authenticated API that provides the required publication lifecycle. A basic metadata deployment should not be assumed to perform all the same steps as the documented Agentforce publishing flow.

I would not consider the Salesforce-only design proven until it completes the full lifecycle in a clean subscriber org. Salesforce's current Named Credentials model is the appropriate starting point for authenticated Apex callouts.

Agent setup is really a step-by-step state machine

Agent publication should not depend on an open browser request. The system needs to remember which step it is currently on, even if the page is refreshed or something fails.

Each stage should persist its status, a safe diagnostic, whether the failure is retryable, and the required recovery action. The LWC can then refresh without losing the operation, and a second click can resume an existing job instead of creating another agent.

The setup process also needs duplicate protection, often called idempotency.

idempotency key =
subscriberOrgId + agentApiName + templateVersion + configurationHash

Before starting a new setup, the system checks that key to see whether the same request is already running or has already finished:Running: resume or return the current job.

• Completed: return the existing result.

• Failed: apply the retry policy.

• Missing: create a new job.

Without idempotency, a browser refresh, Queueable retry, or lost response can create duplicate agents or versions.

Then I found the harder problem: upgrades

Getting version 1 installed is not the real test of an ISV architecture. Upgrading it safely is.

Customers may customize the agent after installation. A later ISV upgrade must preserve those changes instead of overwriting them.

A safer model tracks three layers independently:

ISV base template
        +
subscriber configuration
        +
protected customer customization
        =
proposed agent version

The setup and upgrade process should track the template version, package version, customer configuration, agent/version ID, rendered-script hash, publication result, and rollback target.

An upgrade can then:

1. Detect the installed package and agent template versions.

2. Identify subscriber-owned changes.

3. Produce a new draft rather than overwrite the active version.

4. Validate namespaces and action signatures.

5. Test the proposed version.

6. Require administrator review when changes are material.

7. Activate only after validation.

8. Preserve the prior version as a rollback target.

Architect's takeaway: package upgrades and agent upgrades are related, but they are not the same lifecycle.

What I would validate before calling it production-ready

Architecture diagrams are helpful. Clean-org failure testing is better.

The production validation suite should cover:

• Clean package installation and Agent Installer initialization.

• Agentforce feature, license and permission checks.

• Namespaced action resolution.

• Agent Script compilation and publication.

• Correct runtime-user assignment.

• Duplicate clicks and browser refreshes.

• Expired authorization and deployment timeouts.

• Invalid action references and invalid Agent Script.

• Package upgrades and changed action signatures.

• Customer-edited agents and protected configuration.

• Failed upgrades and rollback.

• Package uninstall while provisioned agent metadata remains.

This is where a proof of concept becomes an ISV product.

The architecture I would validate first

Based on what I learned, I would validate the hybrid model first. I would keep the publishing implementation behind an abstraction such as:

public interface AgentPublisher {
    PublishResponse publish(AgentProvisioningJob job);
    JobStatus pollStatus(String externalJobId);
}

With implementations such as:

AgentPublisher
  ├── HybridServicePublisher
  └── SalesforceNativePublisher

The LWC, setup flow, templates, customer configuration, and upgrade logic should not depend on how the agent is published.

If Salesforce later provides a package-safe API that supports the full publishing lifecycle, only the publishing layer needs to change.

The bigger idea I took away

I started this experiment by asking:

How can I package an Agentforce agent?

I ended it with a better question:

How should an ISV manage the complete lifecycle of an agent across customer organizations?

The product is not simply an agent inside a package. The lifecycle itself becomes part of the product:

Install capabilities
        ↓
Validate subscriber
        ↓
Provision and publish
        ↓
Test and activate
        ↓
Observe and upgrade
        ↓
Preserve customer intent
        ↓
Roll back safely

The managed package supplies the reusable building blocks. The setup process turns them into a customer-specific agent. Later upgrades can then add ISV improvements without losing what the customer configured.

That is the architecture I believe can turn Agentforce distribution from a manual implementation exercise into a repeatable ISV product capability.

If you are an ISV experimenting with this

You do not need to build the complete provisioning platform on day one. Start by validating the package-to-agent boundary end to end:

1. Package one global invocable Apex action. Keep the business logic simple so you can focus on validating the packaging and Agentforce integration boundary.

2. Install the package in a clean subscriber org. Confirm that the packaged action and required permissions are available through the managed namespace.

3. Create the subscriber-side Agent Script and bind it to the packaged action. Define a simple capability in Agent Script, then reference the action installed in step 2 through the managed namespace.

   target: "apex://pk4_agentforce__PK4ProjectHealthAction"
   

4. Publish the Agent Script as an authoring bundle. This creates the subscriber-side agent definition while keeping the business capability in the managed package.

5. Configure the runtime user and assign the required permissions. The runtime user must be able to execute the packaged action that the Agent Script references.

6. Test the complete flow through the agent. Verify the full chain:

   Agent → Agent Script → namespaced packaged action → response

7. Only after that works, automate the lifecycle. Once the package-to-agent boundary is proven, add the installer LWC, orchestration, publishing abstraction, idempotency, upgrade handling, and rollback.

The important part is not completing a list of separate steps. It is proving one connected flow:

Package capability → reference it from Agent Script → publish the agent → grant runtime access → invoke the packaged capability successfully

That sequence is what made the architecture click for me.

Sometimes the most useful discovery is not finding the API you expected. It is realizing that you were solving the wrong boundary.

How are you approaching agent distribution, subscriber-specific configuration, upgrades and rollback for ISV-built Agentforce products?