Data integration connects records from separate systems so people can answer a business question using them together. The connection needs to preserve what the records identify, when they apply and what their values mean. Choose a recurring decision that draws on several departments. Build its connections and business model around the answer the decision owner needs.
A department manager wants to understand why staffing costs changed while output stayed steady. Finance has the spending, HR has the assignments and operations has the completed work. Each team can produce an extract. The manager still needs those extracts to describe the same department and period.
After the transfer, someone still has to reconcile those extracts. The integration should do that repeated preparation and leave the manager with records that support an explanation.
Start with a shared decision
A useful integration begins with a decision that draws on more than one department. Knowing who makes that decision helps the team select the records and decide how current they need to be. The team can demonstrate progress by showing how that decision becomes easier to make.
For a staffing review, the question might concern the relationship between paid hours and completed work. That calls for payroll, worker assignments and operational volumes. A broader request to connect every system gives much less guidance about what should become usable first.
The business owner decides what the measure means. The implementation team translates that decision into source selection, calculations and a report or investigation. Keeping those responsibilities connected prevents a technical delivery from ending before the result reaches daily work.
Match records at the right level
Records describing the same activity may represent different things. One payroll row may contain a payment. Several HR rows may describe that worker's assignments. Joining them on worker ID alone can repeat the payment against every assignment.
The model needs a clear statement of what one row represents. It also needs rules for relationships that change or have several valid matches. An allocation across departments requires an explicit basis, such as assigned hours, before the resulting totals can be interpreted.
Names are a weak substitute for those relationships. Two systems may use different names for the same department, or reuse a name after a reorganization. A maintained mapping between source identifiers gives analysts something they can inspect and reuse.
This is where reconciliation has a useful purpose. Totals before and after a join reveal whether records were lost or multiplied. Unmatched records need a visible status so a report cannot present an incomplete population as complete.
Keep the history the question needs
A historical report needs the relationships that were valid in its reporting period. If a worker moved departments in October, September's payment may still belong to the earlier department. Using today's assignment can change the apparent performance of both departments.
Effective dates describe when a record applies. Extraction dates describe when the platform received it. Both can matter when an earlier period receives a later correction. Retaining the distinction allows a review to explain whether the business changed or its recorded history changed.
A recurring report needs a stated treatment of later corrections. Figures approved at close can be retained for that closed-period report. A current analysis can include the corrections, provided the report identifies that choice. Giving each answer a clear date and definition prevents an unnecessary dispute about which report is right.
Choose the source access route
The analysis determines what the access route must preserve. Live queries can help the team inspect current records. If the source replaces old values, a retained copy may be needed to answer historical questions and repeat an earlier analysis.
Scheduled loads also separate reporting activity from the source application's workload. A monthly staffing review can wait for a complete period. An operational exception alert may need more frequent updates. In either case, the refresh should account for when the source record becomes complete.
Source-specific extraction matters here. Workday and Workday RaaS expose business data through different routes. SAP HANA and SAP SuccessFactors serve different source models. Epic Clarity data reflects the institution's configuration, so a connection alone does not establish the meaning of a local field.
Databasin supports these source routes and can work alongside Databricks, Snowflake or Microsoft Fabric. Its team connects the records and builds the business views around the intended use. That lets an organization improve access to its information while retaining a platform that already serves useful work.
Give reports and AI shared definitions
Reports and AI can reuse a business model for questions about the same measures. The model holds the joins, dates, exclusions and calculations that those questions depend on. A new chart can then use an established measure without someone reconstructing its definition. Raw records remain available to the implementation team for investigation.
In a layered design, raw records enter bronze, validation and standardization happen in silver, and gold presents the business views. Each stage has a different purpose. The prepared view needs a defined meaning and completed checks before people can rely on it.
For an AI investigation, access and evidence belong in the design as well. A read-only agent should receive the permitted views and return the query supporting its explanation. Access to the connected data permits investigation. The decision owner assesses the resulting evidence and retains authority over any operational change.
Keep the integration useful
Source and process changes create work after an integration is running. A new status or department structure can change a report's meaning while its scheduled jobs continue to succeed. Monitoring therefore needs to cover the result as well as the transfer.
The delivery team can test agreed totals, investigate unmatched records and maintain the mappings behind the business views. It can also explain changes to recipients and update the report or workflow when the work changes. These responsibilities should continue after the first connection runs.
Recipients may continue using a familiar spreadsheet until they understand the new report. During rollout, the delivery team can show how to trace a number and raise a question about its definition. Success is the recurring decision becoming easier to make with evidence people understand.
Example: explaining workforce cost
The following illustrative review follows September payments through the historical assignments needed to explain a department's workforce cost.
| Review step | Record or rule | Result available to the manager |
|---|---|---|
| Select September | Payments dated 1–30 September; hours measured in hours | The manager sees which month the payment and hours represent |
| Match assignments | Worker and department relationship valid on each payment date | Payments follow the department assignment valid at the time |
| Check unresolved records | A payment has no matching assignment | Status: Held for review; the unmatched payment is identified separately |
| Add operating activity | Completed units for the same department and period | The report calculates paid hours for each completed unit |
| Publish the review | Reconciled totals and resolved assignment exceptions | Status: Ready; the manager examines the change and its supporting records |
The integration makes the relationship between staffing and output inspectable. The manager can then investigate the operational reasons for a change.
Decisions before implementation
- Select the first decisionChoose the recurring decision that needs information from several departments. Agree what its owner should be able to understand from the result.
- Set the historical meaningDecide whether the analysis uses the record approved at close or the latest corrected history, and distinguish those views clearly.
- Approve shared definitionsApprove how the measures and department relationships should work. The implementation team uses those decisions to build and test the shared model.
- Choose ongoing supportAgree who maintains mappings, resolves exceptions and helps recipients use the result as source systems and business processes change.
Sources
AWS, What is Data Integration?, accessed 2026 · aws.amazon.com/what-is/data-integration
Talk about connected business information
We can discuss the questions that cross your departments and where reconciliation delays the answer. A demo can show how our team connects the sources, defines the measures and helps people use the result.