Name the actual business action
Connect our website to ERP is a starting sentence, not a complete brief. Does the website need to read availability, prepare an order draft or create a customer record? Each action has different consequences. Pick one transaction and describe who starts it, what information it needs and what the user should see when the operation finishes.
Confirm the system and its interfaces
Record the exact ERP product, deployment and version with the system owner. Ask which interfaces are supported for your setup and what access is approved. Do not assume that an integration built for another installation can be reused unchanged. A demonstration with sample data should establish the proposed interface before the project depends on it.
Agree on ownership and mapping
Customer names are not always reliable identifiers. Two systems may represent branches, units or document states differently. Make a mapping sheet with example values and someone responsible for resolving mismatches. Decide which system owns each field and what should happen when the other system disagrees. Without that decision, synchronization can keep replacing one correction with another.
Ask what happens after a timeout
Suppose the receiving system creates a document but the connection drops before your website receives confirmation. What will the user see, and how will the team check whether the action succeeded? Agree on duplicate prevention, reconciliation and an escalation owner. Include those answers in the handover. A working connection needs an operating process for the days when the network is unhelpful.
A concrete brief to send before discovery
That example is deliberately narrower than synchronize everything. Confirm the actual system, interface and permission model with the ERP owner before agreeing implementation. The CeBrief listing describes a separate ERP-oriented product; it is not proof that your company-specific connector is already installed or validated.
- Business action: read approved order status for an existing customer reference.
- Identity mapping: show example references from both systems using fictional or redacted records.
- Acceptance cases: known order, unknown order, missing permission and destination timeout.
Turn discovery answers into an integration brief
Finish discovery with an assumptions register. For each unanswered point, name the person who can confirm it and explain which part of the estimate depends on that answer. Separate an approved requirement from a suggested approach. If the system owner later changes the supported interface or test access, revisit the affected scope before implementation continues. This keeps the discussion useful for both the business and technical teams. A clear register also helps prevent a familiar product name from being mistaken for proof that every required operation is available in the current deployment.
Describe one transaction from start to finish
Begin with a sentence such as display the approved status of an existing order to an authorized user. Then name the initiating system, required reference and expected result. Ask the business owner what should happen when the order is missing, cancelled or outside the user scope. This is more actionable than synchronize the ERP because it creates an acceptance boundary. Include a simple diagram if several systems are involved, but keep the transaction definition in plain language. The person approving the business behavior should not need to interpret an architecture drawing to understand what the integration will do.
Get representative identifiers into the mapping sheet
Prepare fictional or approved redacted examples showing how the same entity appears in each system. Include branch, company and status information where relevant. Ask whether an identifier is stable and unique within the intended scope. If a customer reference can be reused in different companies, the mapping needs that additional context. Do not assume that matching names establish identity. Record who resolves unmatched records and whether a correction belongs in the source system or in an approved mapping table. These choices determine how the integration behaves after the first neatly prepared demonstration.
Write the permissions separately from the data mapping
A field being available through an interface does not mean every application user should see it. Identify the service access and the business-user access required for the transaction. Ask the system owner how those permissions are approved and reviewed. Read-only reporting and document creation should have distinct scope statements. Keep secret values out of the discovery document; describe their purpose and the approved configuration process instead. Where a test environment is required, confirm its access and representative data before committing to implementation dates that depend on being able to exercise the interface.
Agree on acceptance before connecting production
Test an uncertain outcome rather than assuming failure
Consider a request that reaches the receiving system but loses its response on the way back. The integration cannot safely infer from the missing response that nothing happened. Agree how an operator can check the destination using a request or document reference. Define when automatic retry is permitted and when reconciliation comes first. Put the resulting instructions in the acceptance plan alongside ordinary success cases. This makes the operating responsibility concrete and helps the team evaluate an implementation beyond whether it can exchange data under ideal conditions. Production readiness includes resolving ambiguity without creating a second business action.
Frequently asked questions
Can discovery confirm compatibility without interface access?
It can identify likely requirements and open questions, but a compatibility claim needs the actual product details and supported access path. Separate assumptions from verified findings. Record which technical checks remain before a connector is considered suitable for the installation.
Should all master data be synchronized first?
Only if the agreed transaction requires it. Start with the identifiers and fields the workflow actually consumes. Expanding into broad master-data synchronization introduces ownership, conflict and correction decisions that may deserve a separate scope and acceptance process.
A fictional status-lookup scope ready for review
A company asks for an order-status page for its internal support team. A focused first brief might permit an authorized user to enter an existing reference and read a limited status from one approved company scope. The brief names the relevant date and status definitions, identifies the destination owner and includes fictional examples for a known order, an unknown reference and a record outside the user permission. It does not quietly include customer creation, document posting or synchronization of every master-data table.
During discovery, ask the system owner to confirm the supported access route and the way the application identifies the company and record. Treat each unverified point as an open question with an owner. If the interface cannot provide a required field, discuss a narrower result or another approved approach before promising the original behavior. Use the examples to define acceptance and reconciliation instructions. This produces an estimate based on an understood transaction rather than a broad product name. The example is illustrative; no compatibility with a particular installation is established by this article or a portfolio screenshot.
- State the read-only transaction and company scope.
- Mark assumptions that still need system-owner confirmation.
- Keep unrelated write operations outside the initial estimate.
Explore related CoreBiz AI resources
The links below connect this guide to the relevant CoreBiz service and project. Check the project page for its current features and access requirements before using the live tool.
Prepared with AI assistance. Business and learning scenarios are illustrative; no customer results, hiring outcomes or performance guarantees are implied.
Discuss a focused implementation
Explore the service scope and share the process you want to improve.
Explore this service