Recommended resources
The freely available resources this lesson will direct you to.
Hello again. In the previous lesson, you traced a trial balance from customer export to its first usable state in a draft report. That map showed what must happen to the data. This lesson asks who makes it happen—and who has the authority to decide that it may happen at all.
For a product manager, “the customer will set up the integration” is too vague to guide onboarding design. The person who connects a source may not control access to its data; the person who approves access may never use the resulting report. You will identify five roles in a customer ingestion journey—implementer, administrator, data owner, risk reviewer, and end user—and distinguish the actions, decisions, and concerns associated with each.
Start with authority, not job titles
A useful distinction is between accountability for data and day-to-day work on data. Watch this short explanation before applying it to the onboarding journey.
What is the difference between Data Owners and Data Stewards?
Watch “What is the difference between Data Owners and Data Stewards?” from The Data Governance Coach. It clarifies why the person accountable for a dataset need not be the person doing its daily work.
Watch owner and steward for the distinction between senior accountability and operational expertise. Then watch smaller organizations for the qualification that one organization may combine roles rather than staff each separately.
The diagram below adds two useful perspectives: technical custodians maintain the systems that hold or move data, while users depend on the result. Treat it as a governance sketch, not a literal staffing chart for every customer integration.
The following reading sharpens the distinction between technical care and downstream use.
Data Steward vs Data Owner: Roles and Responsibilities Explained
Read the discussion of custodians and consumers in Soda’s “Data Steward vs Data Owner: Roles and Responsibilities Explained.” It helps distinguish the person moving data from the person interpreting or using it.
In “Where These Roles Fit in the Governance Operating Model,” find the paragraphs beginning “Data custodians” and “Data consumers,” immediately after “Beside them, two other groups matter.” Read both descriptions, stopping before “How this scales depends on the governance model.” Focus on what a custodian can fix, what a consumer can notice, and why neither fact alone establishes authority to approve a new use of the data.
For ingestion discovery, the five roles below are more actionable than a generic governance chart. They are responsibilities to locate, not necessarily five distinct employees or five application permission levels.
| Role | What they do in the customer journey | What they must be able to decide or verify |
|---|---|---|
| Implementer | Performs the integration work: configures an export or connection, maps fields, tests a file, and investigates setup failures. Often an engineer, integration specialist, or technically capable operations colleague. | Can the source produce the needed data, and does the configured flow work? They may need someone else to grant permissions or approve the transfer. |
| Administrator | Manages the customer’s source-system or product workspace settings: creates accounts, assigns permitted roles, maintains a connection, or manages ongoing configuration. | Is this person authorized to make the required configuration change? Being an administrator of the fintech product does not automatically make them an administrator of the customer’s accounting system. |
| Data owner | Is accountable on the customer side for a data domain, such as finance or payments data, and for its authorized use. | May this dataset be shared for this purpose, with these people and conditions? They can delegate routine work without losing accountability. |
| Risk reviewer | Examines whether a proposed connection and data use meet the customer’s security, privacy, compliance, or third-party-risk requirements. This might be a security or compliance colleague rather than a person with “risk reviewer” in their title. | What evidence, restrictions, or approval does customer policy require before activation? Whether their review is an approval gate depends on the customer and the risk. |
| End user | Relies on the product’s output: for example, a finance analyst inspecting a draft report or an operations colleague reviewing received payment instructions. | Is the result understandable and useful for the intended task? They can reveal a bad mapping even when the connection is technically healthy. |
These roles answer different questions. The implementer can demonstrate that an export works; the data owner can authorize its use; the end user can establish whether the result serves the task. None of those is a substitute for the others. The risk reviewer assesses the proposed controls and exposure, while the administrator provides or maintains the appropriate configuration within their authority.
Put the roles on the trial-balance journey
Return to the trial balance from the previous lesson. The customer exports account balances for a known entity and closing period. The product parses account rows, preserves codes such as 0010, maps them to reporting categories, and—if the required checks pass—makes the result available in a draft report.
Imagine onboarding that customer. An implementer might first test whether the accounting system can export the required accounts and period consistently. If the export requires a service account or a scheduled job, a source-system administrator may need to configure it. A different product administrator might invite the implementer into the fintech workspace. A setup screen that says only “ask your admin” conceals this distinction and may send the customer to the wrong person.
Before balances move into the product, the data owner needs to establish that sharing this financial dataset for draft reporting is authorized. The owner might also identify who has authority to approve the customer’s account-to-reporting-category mapping. An implementer can load a mapping supplied by finance, but should not have to invent the meaning of an unfamiliar account code merely to clear a setup error.
The risk reviewer may ask where the export is sent, which fields it contains, who can see it, and whether the proposed connection satisfies the customer’s controls. This is not a universal requirement for a separate approval on every trial-balance import. It is a role to identify so the product team does not discover an approval requirement only after building a supposedly self-serve flow.
Finally, the end user opens the draft report. They may notice that an account appears under the wrong category despite the file having passed structural checks. Their feedback identifies a problem with business usability; the data owner or an authorized finance delegate resolves what the account should mean, and the implementer or an operational data steward may apply the correction.
The handoffs matter as much as the individual roles. If the product displays “mapping incomplete,” who receives it? If changing a mapping alters a report already in use, who may authorize the change? If the implementer leaves after launch, who maintains the connection? These are product requirements hidden inside what initially looks like a simple upload journey.
Locate the real people behind the roles
Customers will not necessarily use these labels. In a small organization, one finance operations lead might administer the product, own the trial-balance data, and use the report. In a larger one, an integration team might implement the connection while finance owns the data and a separate security team reviews the transfer. Combined roles are workable; unassigned decisions are the problem. Where a change could expose sensitive data or materially alter an output, do not assume that holding two operational roles also confers independent approval authority.
Discovery is more reliable when you ask about specific actions and decisions rather than requesting an org chart. For the trial-balance journey, a PM would seek answers such as:
- Who can generate the export and troubleshoot its format? Who can grant that person the needed source access?
- Who decides that these balances may be sent to the product for draft reporting?
- Does anyone review the connection or data-sharing arrangement before production use, and what evidence do they require?
- Who confirms that account categories make business sense? Who notices and reports an error after launch?
- Who takes over connection maintenance when the original implementer is no longer involved?
Record a role’s customer-side owner, required action, decision authority, and point in the journey. If the person is not yet known, record the gap rather than assigning the decision to “the customer.” Also distinguish customer and platform responsibilities: the platform may provide setup checks, diagnostics, and support, but it cannot assume authority to approve a customer’s internal data use.
The same questions transfer to an ACH ingestion journey, though the answers may differ. An implementer can deliver and test an ACH file; an administrator can manage the connection; a data owner can authorize sharing payment-instruction data; a risk reviewer may scrutinize access to sensitive receiver details; and an operations end user can confirm whether the view supports investigation. The end user’s ability to see an instruction still does not establish that a payment settled. That limit, from the previous lesson’s definition of “first usable,” should shape both the product’s claims and the people asked to validate them.
Key takeaways
A customer ingestion journey involves more than the person clicking “connect.” Identify who implements, who administers, who owns the data decision, who reviews risk, and who uses the result. Map those roles to concrete handoffs and approvals, allowing one person to fill multiple roles without treating technical access as automatic business authority.
In the next lesson, you will segment prospective customers by their source systems, data volume, freshness needs, and integration capabilities. The role map will help explain why two customers with similar datasets may still face very different onboarding effort.