Systems Place Insights

Read-only AI access to ERP and CRM data: questions to ask before launch

Sun, 19 Jul 2026 11:50:28 GMT

A useful business decision starts with evidence people can inspect. Read-only access to ERP and CRM data can help assemble that evidence, but it does not establish that the answer is correct or that every user may see it. Define the question, the access boundary and the decision owner together.

Begin with the decision

Choose one recurring decision: which order needs attention, why margin changed, or where a quality issue first appeared. Record who makes the decision, which records matter and what would count as enough evidence to act. A broad instruction to “analyse the business” is difficult to evaluate or authorise.

Identify a report, calculation or known result that the business already trusts. This gives reviewers a reference point for checking definitions, scope and source timing. It also makes a disagreement useful: the team can investigate the evidence instead of comparing confident-sounding answers.

Make read-only a technical boundary

An approved read path should retrieve only the data needed for the question. It should not create, update, delete, approve or submit records. Enforce that restriction in the exposed tools and source permissions; instructions in a prompt are not an access control.

List the allowed operations and the fields each operation can return.
Restrict the companies, territories, records and periods in scope.
Separate an empty result from a denied or failed request.
Test an attempt to call an unapproved operation.

Give each request an identity

Document how the person asking the question maps to the identity used at the source. The source may see that person, a technical account or both. The design should make the effective permissions clear and allow access to be revoked without ambiguity.

Test people who should receive different results as well as people who should receive no result. Include restricted fields within otherwise accessible records. A correct total is still an unacceptable answer if it discloses information to the wrong person.

Keep the evidence inspectable

Record which source, period, business definition and filters support an answer. Make missing or stale evidence visible. If a source cannot answer the question, the response should explain that limit instead of presenting an unsupported estimate as a fact. Existing business systems remain the source of record.

Trace the request through the assistant, connection, source and any retained logs or caches. Review the actual provider, plan and workspace settings for the intended deployment. The assistant compatibility reference describes the questions to check without assuming that every combination works.

Separate a recommendation from permission to act

Finding a margin exception and changing an order are different capabilities. A later action needs its own scope, preconditions, permissions, approval rules and failure handling. A user’s ability to read a record must not silently become permission to change it.

Decitera follows Understand, Decide, Act, Measure. A bounded read-only use case can begin with an evidence-backed recommendation for a named person to consider. Any system action remains subject to explicit authority and an agreed scope.

Agree the acceptance record

Before launch, record the approved question, users, sources and operations; the results of allowed and denied access tests; representative answer checks; and the person responsible for acceptance. Include the conditions that require a new review, such as a different source or business definition.

Read the security and data handling approach for the wider boundary, or bring one decision to Systems Place to explore the smallest useful starting point.

How to check AI answers against the business reports you already trust

Sun, 19 Jul 2026 11:50:28 GMT

An answer becomes useful when the business can explain why it should be trusted for a particular decision. Compare AI-generated analysis with reports, calculations or known results before relying on it. The aim is a clear acceptance boundary, with evidence and limits that a reviewer can inspect.

Turn a question into a testable decision

Write down the exact question, the person responsible for the decision and the evidence they need. “Why did margin fall in the northern region?” is incomplete until the team agrees what margin means, which period is being compared and which transactions belong to that region.

Specify the measure, period, currency and organisational scope.
Agree the treatment of returns, cancellations and late changes.
Name the trusted comparison and the person who understands it.
Define acceptable differences before reviewing the answer.
Record the circumstances in which the system must decline to answer.

Use more than a successful example

Choose a compact set of representative questions. Include ordinary cases with known results, business exceptions, period boundaries and incomplete evidence. Add questions from users with different permissions, and questions outside the approved scope.

A missing source should produce a visible limitation. A denied request should remain denied. An unsupported question should not receive a plausible substitute presented as a verified result. These behaviours matter as much as the successful path.

Reconcile the result and its reasoning

Compare the headline result, then inspect the records, filters and definitions that produced it. A variance may reveal a defect, a source-timing difference or an undocumented rule in the trusted report. The reviewer needs enough evidence to distinguish those explanations.

Require exact agreement when the business rule calls for it. Where rounding, currency conversion or timing makes exact agreement unsuitable, agree the treatment in advance. Do not choose a tolerance simply because it accommodates the observed answer.

Evaluate the proposed action separately

A sound explanation does not automatically justify its recommendation. Ask whether the proposed action addresses the stated decision, which alternatives were considered, what constraints apply and who may approve it. The evidence may support further investigation rather than an immediate change.

If an action changes a business record, test the approval boundary and permitted operation separately from answer quality. A calculation can be correct while the action is unauthorised, duplicated or aimed at the wrong record. Record the policy version used to evaluate permitted options.

Leave a decision record

For each case, keep the question, source evidence, expected result, observed result, material differences and reviewer’s conclusion. When a recommendation leads to action, retain the evidence, rationale, authority, action and result as a connected decision record.

Decitera’s Understand, Decide, Act, Measure loop keeps evidence connected to the decision it informed. Verify that an authorised action executed as intended, then separately measure whether it produced the desired business outcome. A successful system response is not proof of a successful business result.

Recheck when the decision context changes

An accepted answer is evidence for a bounded use case, not a guarantee that every future question will behave the same way. A different source, definition, user group or action changes the acceptance boundary. Repeat the relevant checks and record the new decision.

Use observed outcomes to improve evaluation cases without quietly widening permissions or changing agreed rules. See how the work moves from a decision to evidence and outcomes, or discuss a first use case with a report or known result you already trust.

Native ERP AI, BI, a platform or custom MCP: how to choose

Sun, 19 Jul 2026 11:50:28 GMT

Choose the route that supports an agreed business decision with approved evidence, explicit controls and a named owner. The right starting point may be an existing ERP capability, a BI model, a platform or a purpose-built connection. It may also be a clearer definition or no additional software.

Compare decisions, not feature lists

Begin with one recurring decision and the people responsible for it. Identify the sources involved, the trusted comparison and the action the answer could inform. Then ask what each route must do to reach the same useful outcome.

Separate what is required now from what might become useful later. A team that needs an inspectable explanation may not need automated execution. A team that needs to change a business record must evaluate permissions, approvals and action evidence as distinct requirements.

Consider the smallest useful route

Native ERP or CRM capability

Evaluate a native capability when the question sits within one source system. Check whether the actual configuration can reach the required records, apply the agreed definitions and respect the intended users’ permissions. Verify the selected product and deployment directly; a general feature description is not evidence that a particular use case works.

Existing BI

An approved BI model can provide shared measures and a trusted comparison. Evaluate whether it already answers the question, whether the evidence can be inspected and whether any proposed assistant access preserves its permissions. A familiar dashboard may remain the best interface for a stable recurring question.

A decision platform

A platform is worth evaluating when the requirement spans several sources and needs a consistent connection between evidence, decisions, actions and outcomes. Review the data boundary, ownership, approval rules and portability of the resulting records. Existing business systems should remain the source of record. Do not assume that buying a platform resolves disputed definitions or missing source access.

A purpose-built MCP connection

Model Context Protocol, or MCP, provides a way for compatible AI applications to connect to tools and context. A purpose-built connection may fit a bounded operation that existing routes cannot provide. The protocol does not determine the business meaning of the data or establish the correct permissions and approval policy; those remain explicit design work.

Prerequisite work or no build

If the source is incomplete, the measure is disputed or no one owns the decision, address that gap first. If an existing report already supports the decision well, improving its clarity may deliver more value than another interface.

Apply the same acceptance criteria

Evidence: Can the route reach and explain the required sources, periods and definitions?
Access: Can it enforce who may see data and who may request an action?
Evaluation: Can representative results be checked against trusted evidence?
Decision ownership: Is there a named person and a clear approval boundary?
Outcome: Can the team establish whether the decision produced its intended result?
Portability: Can the evidence, definitions and decision records be understood outside the chosen tool?

Make the route decision before the build decision

Record the preferred route, alternatives, assumptions and evidence that could change the conclusion. This makes the choice reviewable and prevents a technology preference from becoming an unstated requirement.

Decitera connects business evidence to governed decisions through Understand, Decide, Act, Measure. Start with one application, compare the practical routes, and discuss the smallest useful next step.