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.