Who to hire for Regrello and Agentforce Operations

Most Salesforce partners are good at the front of the house: selling, marketing and serving customers. Regrello pointed at the other end of the business, where an invoice is matched against a purchase order in one system, checked against a contract in another and approved by email. Salesforce bought it to automate that kind of work, and the people who can do so are not always the same people who configure Sales Cloud. That difference is the whole hiring problem.

#What was acquired and what you can buy

Salesforce described Regrello at signing as "an AI-native solution that automates complex business processes", and completed the acquisition on 1 October 2025. The announcement said Salesforce planned to integrate Regrello with Agentforce and Slack. The full text is on the Salesforce newsroom.

The product that followed is Agentforce Operations. A Salesforce blog says plainly: "Agentforce Operations, powered by Regrello, turns human-first processes into AI-first operations." Constellation Research reported its general availability on 29 April 2026. According to Salesforce's own description, it centres on a super agent called Marshall that builds a process from a conversation and runs it, a Systems Integration Agent that learns browser-based applications, and a process-mapping capability that shows how processes actually run. The same post says steps that must run the same way every time run deterministically, that the work has an audit trail, and that people are notified in Slack, Teams or email only when a decision needs them.

We found no Salesforce document giving pricing for Agentforce Operations, and Constellation's report contained none, so licensing is a conversation with your account team. Treat any partner who quotes a licence figure from memory with suspicion. The licence guide explains what is and is not published.

#Why this hire is different

A back-office process lives across systems of record such as an ERP, a procurement tool, a contract repository and a bank portal. Salesforce may hold only a small part of it. The partner therefore needs three kinds of knowledge at once: the business process, the surrounding systems, and Salesforce's agent platform. The mix differs from a Sales Cloud project in important ways.

The process knowledge is domain-specific. Someone who has run accounts payable understands why a three-way match exists, what a duplicate payment costs and who is allowed to release a payment. Someone who has worked in procurement understands supplier onboarding, tolerance rules and the awkward exceptions. A pure Salesforce consultant can learn these, but not in your timeline.

The controls knowledge is where projects stall. Auditors ask who approved what, whether the same person can create and release a payment, and where the evidence is kept. A partner who has never answered those questions will treat them as an afterthought and be surprised at the review.

The platform knowledge is new for everyone. Agentforce Operations is a recent product, so no firm has a long track record on it. Ask for the nearest relevant delivery, such as Agentforce deployments or workflow automation in finance, and be honest with yourself about how much risk you are carrying.

#Credentials and skills to check

We read Trailhead's consultant, developer and architect credential lists on 13 October 2026 and found no credential named for Agentforce Operations. Useful related names are the Salesforce Certified Agentforce Specialist, the Salesforce Certified Platform Integration Architect for the connections to your other systems, the Salesforce Certified Business Analyst for process discovery, and the Salesforce Certified Platform App Builder if Flow forms part of the design. You can verify each on the consultant, developer and architect pages.

Beyond Salesforce, ask about process analysis, finance or supply-chain domain experience, internal-control design and change management for the teams whose work will change. In this kind of project, adoption is as often the failure point as technology.

#A process inventory as the first engagement

Do not start with a platform build. Ask the partner to inventory your cross-system processes and score them. A good output is a short table, one row per process, showing:

• The systems touched, and whether each offers an interface or only a screen.
• Volume and frequency, with elapsed time and the effort people spend.
• The proportion of cases that follow the standard path and what the exceptions are.
• The controls that apply: approvals, limits, segregation of duties and evidence.
• The cost of an error, such as a duplicate payment or a late shipment.
• A judgement on fit: suitable for an agent, suitable for plain deterministic automation, or best left with people.

From that table, choose one process for a first live release. The Salesforce blog's own examples, an invoice audited across several systems and a closed deal waiting on credit checks and provisioning, are the right size and shape. Ask the partner to document the target process, the controls and the measures before building anything. The implementation guide follows a single process through that cycle.

#Red flags specific to this product

Treating it as a Flow replacement. Salesforce Flow remains the right tool for rules inside Salesforce. Agentforce Operations is aimed at long-running work across several systems. A partner who proposes to rebuild your Flows in it has misread the product, and one who says Flow is obsolete is selling.

Treating it as a chatbot. The value is in a process that "holds its state for as long as the work takes", in Salesforce's words, which may be weeks. Ask how the design copes with a supplier who replies after ten days.

Over-trusting the learning claim. Salesforce's post says the Systems Integration Agent learns a browser-based application "in about 90 minutes, with no code, no APIs, and no RPA". That is a vendor claim about the product under good conditions. Ask the partner to demonstrate it on one of your applications, including a login with multi-factor authentication, and to explain what happens when a screen changes.

Vague answers on determinism. Payments, approvals and postings need predictable behaviour. Ask which steps in the proposed design are deterministic, which use model judgement, and how the second kind is checked before anything irreversible happens.

No owner for the process afterwards. Processes change. If nobody on your side is named to adjust them, the automation will drift out of line with the business within months.

#The people side of back-office automation

Front-office projects have users who chose their job because they like the product. Back-office projects have accounts payable clerks, buyers and planners whose daily work is about to change, and who know exactly where the current process breaks. Their knowledge is the best input you have and their goodwill is the scarcest resource. Ask each candidate how they involve those people in discovery, not only managers. A partner who runs workshops with the team doing the work will find the unwritten rules, such as the supplier who must always be phoned or the approver who is never available on Fridays, before they turn into production incidents.

Ask also what the automation does to the shape of the job. If the agent handles routine matching, the human work shifts towards exceptions, which are harder and less predictable. Teams need training for that, and a view from management on how performance will be judged. A proposal with no change plan is a proposal for a tool that people quietly work around.

#Where Slack and Agentforce fit

Salesforce said at signing that it planned to integrate Regrello with Agentforce and Slack, and its later description says people are told in Slack, Teams or email when a decision needs them. In practice, that makes the approval experience as important as the automation. If an approver is asked for a decision in a channel, they need enough context to act without opening three other systems, and a record that the decision was theirs. Ask the partner to show, with a real example, what an approver sees and how the decision is stored. Ask, too, how they handle approvers who are on leave, and what the escalation rule is when a request sits unanswered. These small design choices are what separate a process that runs from one that stalls on the third day.

#Ten questions to ask every candidate

1. Which cross-system finance or supply-chain processes have you automated, and on which tools?
2. What is your nearest experience to Agentforce Operations, and what will you be learning on my project?
3. Show me a process document and control matrix from a past project, with the client removed.
4. Which steps in my process would you make deterministic, and which would use an agent?
5. How do you keep the audit trail, and how would an auditor retrieve it?
6. How do you handle segregation of duties when an agent prepares an action that a person approves?
7. What happens when the Systems Integration Agent meets a changed screen or a login challenge?
8. How do you measure the benefit before and after, and who agrees the baseline?
9. Who on my side needs to own the process afterwards, and how much time will that take?
10. When would you advise me that a process is not worth automating?

#Evidence, references and contract terms

Ask for a reference from the process owner, such as the head of accounts payable, not the technology sponsor, and ask what the controls team thought. Ask to see a measured baseline and a post-launch comparison. If the partner claims time saved, check how it was counted, since "hours saved" is easily overstated. Because the product is new, a smaller number of strong references on adjacent work is more informative than a long list of unrelated logos.

For commercial terms, fix the inventory as its own short piece of work. Price the first process build against a documented design, with acceptance tested on your real cases. Avoid contracts that pay a share of savings unless the baseline and counting rules are written down and audited by someone independent of the partner. Include in the statement of work the controls to be implemented, the audit evidence to be produced, the exceptions routed to people and who owns each, and the handover of process documentation. See the cost guide for how to compare services quotes, and the migration guide if you already run Regrello itself.

#When a project is small enough to skip a partner

If your process sits inside Salesforce, touches one or two objects and needs an approval and a notification, Flow and a capable administrator will serve you well, and an Agentforce Operations engagement is not needed. If the process crosses several systems but is rare, the saving may not justify the build. Where volume is high, errors are costly and the work is spread across systems, a partner is worth the fee, provided the first deliverable is the inventory and not the build. The what happened guide sets out the dates and the product naming in one place.