A new AI interface should make an approved business task easier to complete. It should also preserve the rules that make the result acceptable. Before an assistant can issue a refund, change an account, or commit the company to a customer promise, leaders need evidence that the full process still works.
On September 15, Salesforce introduced AIforce, which brings application data and actions into interfaces such as Claude and Slack. Salesforce says requests use existing permissions and business rules. Its Google Cloud partnership announcement also lists a mix of available features, previews, and planned releases. Customers need to check the specific capability they intend to use. [1] [2]
The broader decision reaches beyond any one vendor. When an employee can ask an assistant to do work that once required opening a business application, the company gains a new way to operate that application. Leaders need to establish where the business rules are enforced and whether every route follows them.
The screen and the business process are different
An interface is the part of a system that a person uses: a form, a dashboard, or a conversation with an assistant. The business process is the work behind it, including the information required, the people allowed to act, the approvals needed, and the record of the result.
In a well-designed system, important controls are enforced by the services carrying out the action. A screen can guide employees, but a warning on a screen cannot protect a transaction that never passes through it. A new interface therefore creates a reason to check where each control actually lives.
This is not a new problem invented by AI. OWASP, which publishes application-security guidance, identifies sensitive business processes exposed through software interfaces as a risk when access is not properly constrained. Its guidance calls for business owners to identify the risk and engineers to implement the protections. [4]
AI adds another route into those processes. An assistant may turn a short request into several actions and connect systems that have different rules. A successful demonstration shows that a task can be completed. Leaders also need evidence that the system rejects, pauses, or escalates the tasks it should not complete.
Start with one transaction that matters
Consider an illustrative customer-refund process. The company allows a service representative to issue an eligible refund of up to $500. A larger amount needs manager approval. Finance records the payment, and the customer receives confirmation only after the payment system accepts it. These amounts and rules are examples, not industry standards.
The representative now asks an AI assistant to refund $800. The assistant may understand the request perfectly. The workflow must still check eligibility, obtain the manager's approval, record the payment correctly, and report its actual status. Good language understanding cannot replace those steps.
Use four checks before expanding access
The LXSGRP recommendation is to test authority, business rules, records, and recovery for each important workflow. Apply these four checks through every intended interface, using the same business conditions.
A successful demonstration shows that a task can be completed. Leaders also need evidence that the system stops the tasks it should not complete.
1 Confirm who is allowed to act. Identify the person or automated service making the request and the actions their permissions allow. Permission to read an account does not authorize a payment. Limit any shared service account's permissions and retain the initiating user's identity.
Test the refund with a representative, a manager, and someone who cannot access the account. Include a user whose access has been removed. Verify the allowed actions for each role; signing in is only the first check.
2 Enforce the business rule where the action happens. For the $800 refund, show that the payment cannot proceed before the required approval. Giving the assistant a written instruction to seek approval is useful guidance, but the system carrying out the payment should enforce that condition. Otherwise, a changed instruction or an alternate route could produce a different outcome.
Check the rule against variations that matter. What happens when approval expires, the refund amount changes, or the order has already been refunded? Approval should apply to the specific transaction. If material details change, the workflow needs to check whether that approval still holds.
The Model Context Protocol, or MCP, is one way AI applications connect to external tools and data. Its tools specification includes input validation, access controls, and logging guidance. The connection makes an action reachable; the implementation still has to enforce the company's business conditions. [3]
3 Keep a usable record of the result. Trace the request to its approval and payment record, then compare the assistant's response with the actual status. A conversation saying "done" cannot establish that a payment happened. Record failed and rejected attempts as well as successful ones.
Give the people responsible for the workflow enough evidence to investigate an error without copying unnecessary customer information into every log. The application owner should define what must be retained, who can inspect it, and how long it is needed. An audit trail that nobody can connect across systems will be difficult to use when a customer disputes the result.
4 Recover without repeating the action. Suppose the payment system accepts the refund but its response never reaches the assistant. Retrying the request could create another payment unless the system recognizes the repeat. This is a known software problem. Amazon's engineering guidance describes designing operations so repeated requests do not cause additional side effects, a property called idempotency. [5]
Test that case before launch. The workflow should identify the original request, check what happened, and avoid paying twice. Also name the person who handles an uncertain result. Some actions can be reversed; others require a separate correction. The recovery plan should reflect that difference.
Measure the full job before adding more users
Choose a narrow pilot with a named business owner and an application owner. Agree the cases that must pass before launch, including ordinary requests, rejected requests, approval changes, and interrupted actions. Begin with the smallest useful set of permissions and expand only when the evidence supports it.
Measure completed work that meets the business rules. For the refund process, useful measures include correct payments, duplicate payments, approval exceptions, time to confirmed resolution, and cases requiring manual repair. Compare the pilot with the existing process over a similar mix of cases. A lower number of clicks has limited value if another team spends more time correcting the records.
The tradeoff is real. More checks can add time and maintenance work. Different interfaces also create more routes to test when a rule changes. The company should weigh that effort against better access, faster completion, and less manual coordination. For a read-only account summary, a lighter test may be enough. A payment or contractual commitment deserves stronger evidence.
Avoid rebuilding the same refund rule separately in every assistant. Where practical, keep the rule in the service responsible for the transaction and have each approved interface call it. That reduces the number of places that must change when the business updates its policy. It also makes inconsistent behavior easier to identify.
Keep choice in the interface without assuming easy switching
Using several assistants can give employees flexibility, but a common connection method does not make whole workflows interchangeable. A second assistant may interpret requests differently, expose different confirmation steps, or provide different records of its actions. Switching can therefore require new testing even when the underlying business system stays the same.
Before expanding a purchase, ask the team to show the same approved task through another supported interface. Identify what can be reused and what must be rebuilt or tested again. This gives procurement and technology leaders a more useful picture of switching effort than a general promise of openness.
Keep product availability separate from that assessment. The September 15 Google Cloud announcement lists the Salesforce Federated Connector for Gemini as a private preview, with general availability planned for late October. A planned release can inform a roadmap, but a production commitment needs a capability that is available and tested for the intended use. [2]
Make the next rollout decision specific
At the next application review, select one transaction that employees want to perform through AI. Ask the business and application owners to demonstrate who can act, how the rules are enforced, what record remains, and how an interrupted action is resolved. Any failed check should have an owner and a clear repair before that action reaches more users.
The LXSGRP recommendation is to make this evidence part of the rollout decision. Approve the workflow when the new interface delivers useful work and preserves the business conditions required to trust the result. Where those conditions are missing, narrow the assistant's role until they are proven.
Join the LXSGRP curated executive community for practical peer conversations about the application, data, and operating decisions facing senior technology leaders.