DataFlow combines data from company systems into an organized reporting source. It shows where the data comes from, how models depend on one another, and which logic produces each column. The team connects sources, checks results, publishes changes, and monitors runs in one application.
More than conventional ETL. If there is no data preparation tool yet, DataFlow builds the process from the ground up. If the company already uses ETL, Alteryx, KNIME, or scripts, it shows how to improve them: transparent logic in SQL and dbt, data lineage, tests, and an AI assistant instead of processes understood by only one person.
DataFlow addresses three common starting points: reports assembled from spreadsheets, processes maintained in a desktop tool, and a self-built data stack that depends on one person.
| Symptom | What it costs the company |
|---|---|
| Reports from different systems do not match | Meetings focus on which figure is correct instead of what that figure means. |
| An analyst spends most of the day preparing data | Specialized expertise is consumed by retrieving, copying, and cleaning data. |
| Only one person understands the process | Vacation, illness, or an employee's departure creates operational risk. |
| A source API change breaks a report | The error can remain unnoticed until someone questions the result. |
| No one knows where a value came from | The team loses confidence in the data and returns to decisions based on intuition. |
| ETL tool licenses are assigned to individual workstations | The cost rises with every person who needs to work with data. |
The platform organizes the path from source data to reporting and makes that path transparent and maintainable. It does not replace every data-related tool.
If all required data is in one system and its reports are sufficient, an additional platform is unnecessary. The tool also does not replace agreement on business definitions or a team's readiness to change its way of working.
A shared reporting reference point, a traceable path from result to source, and a per-instance license instead of fees that rise with volume or user count.
Deployment in the organization's infrastructure or hosting by Astrafox, corporate sign-in, roles, permissions, and a repository history of definitions.
Ready-made connectors, one shared application, documentation created during the work, and an implementation that prepares the team for continued development.
A data engineer builds integrations and models, checks data, and publishes changes. A BI analyst uses the catalog, column descriptions, data lineage, and visual SQL analysis. An administrator manages workspaces, users, roles, credentials, integrations, and the license. Business users continue to work in Power BI, Tableau, Excel, or another tool connected to the data warehouse.
DataFlow loads data into the client's data warehouse, processes it according to transparent logic, and provides ready-to-use models for reports. The AI assistant understands the catalog, models, dependencies, and run history: it explains existing pipelines, prepares proposed changes, and helps identify the cause of an error.
A repeatable process instead of manual work, version-controlled logic, tests before publication, organized data for Power BI, Tableau, Excel, or another tool, and an answer to the question, “Where did this figure come from?”
The data warehouse remains on the client's side. We deploy the platform in the organization's infrastructure or host it at Astrafox.
One license per instance—regardless of data volume, number of sources, or users. The execution engines do not require separate license fees.
The scope depends on source types, connection quality, and the reconstruction of processes from Alteryx, KNIME, or scripts.
The client pays its provider for the data warehouse and for infrastructure if the platform runs in the client's environment.
The client selects the model provider and pays it directly. Astrafox does not resell usage or add a markup.
The number of environments, SSO, network, and security requirements affect the scope.
These cover configuration, comparison tests, training, knowledge transfer, and ongoing support.
Portability: business logic is stored in SQL and dbt, configuration history is kept in a repository, and data remains in the client's data warehouse.
Components, AI models, sign-in, network requirements, offline licensing, change publication, and safeguards are described separately.
Architecture and security →Describe one report or data process, its sources, current technology, and preferred deployment option. During the first conversation, we also establish how the result will be verified and define the migration scope. We then prepare an implementation plan, division of responsibilities, and estimate.
We implement the platform, configure the first sources and models, compare results, and prepare the client's team for continued development.
Systems, business questions, rules, and the current way of working.
Deployment or hosting, sign-in, access, and responsibility.
Connecting data, building layers, and agreeing on definitions.
Comparing results with the existing reporting process.
Training, documentation, and the scope of continued cooperation.
The starting requirements are technical access to sources, a data warehouse or a decision to launch one, and a person who understands the data and business rules. The client's own infrastructure, SSO, and an AI model provider are not required.
We will map the sources and data path and identify the first process to organize.
Describe a data challengeExpand the area to review. Technical details are available on the architecture and security page.
DataFlow lets the team search for a connector, test a connection, and select data sets. Secrets are managed centrally, while workspaces separate integrations, credentials, and roles for departments or companies.
Sources, tables, models, tasks, and processes are described together. The logic covers cleaning, joins, aggregations, and calculations in SQL and dbt, along with tests for completeness, uniqueness, relationships, and business rules.
A change is created outside the live solution. Differences, dependencies, and the publication plan are visible; results can be checked on the data, and an authorized person performs the publication.
The catalog combines descriptions, owners, freshness, tests, and history. A graph shows model dependencies and column-level lineage, while SQL analysis breaks a query into clear stages.
The platform shows consecutive runs, steps, duration, records, and errors. Configuration has a history and version differences, making it possible to determine who changed a calculation method and when.
The assistant explains models, prepares proposed changes, generates their descriptions, and analyzes errors using the solution's current structure. A proposal follows the same validation and publication path as every other change.
We connect ERP and accounting systems, CRM and sales systems, help desks, project and marketing tools, Microsoft SQL Server, PostgreSQL, MySQL, Oracle, and MongoDB databases, Excel and CSV files, Google Sheets, SharePoint, FTP, SFTP, and object storage. We connect custom applications through an API, a database, or a custom connector. During the analysis, we verify the specific connection method.
Customer, invoice, and project settlement data is stored in three places, and the monthly report requires manual reconciliation. We connect the sources, reconcile keys, and build a shared model that runs on a schedule. Every item can be traced back to the source system.
Critical workflows run on individual workstations, and knowledge of some of them left with their author. We analyze the logic and dependencies, reconstruct the processes in DataFlow, and compare control results. Runs move to a server, while the logic becomes transparent and version-controlled.
A recurring report is assembled from several manually downloaded files and a spreadsheet with formulas. We move the rules into models, describe them in the catalog, and set a schedule. The application shows the execution path and the cause of an error.
The team wants to add a metric or change a source but does not know which reports and models depend on it. The team reviews dependencies, analyzes the SQL, tests the result, and reviews the scope. The change has a described impact, a verified result, and a history.
Compared with spreadsheets and desktop workflows, DataFlow centralizes runs, history, tests, and access. Compared with a self-built Airbyte, dbt, and Dagster stack, it adds a shared interface, catalog, data lineage, roles, and implementation and maintenance by Astrafox.
It is a platform for building and maintaining data pipelines with an AI assistant: from connecting sources through logic and tests to publication, schedules, a catalog, and data lineage.
Logic is stored in SQL and dbt, processing takes place in the client's data warehouse, history is saved in a repository, and the catalog and data lineage are built in. The license is priced per instance, not per workstation.
Per instance, regardless of data volume, number of connectors, or users. The client pays data warehouse and AI model providers directly.
No. It uses the client's data warehouse and prepares models that supply Power BI, Tableau, Excel, or another analytics tool.
Not at the start, because Astrafox leads the initial implementation. Continued in-house development requires a person who understands SQL and company data, or continued support from Astrafox.
With a description of one business question, the current reporting preparation method, and the source systems. We use this information to design the first pipeline and the method for verifying the result.
It is not a real-time integration bus. It retrieves data on a schedule or on demand, depending on the source and configuration.
Information about sign-in, network requirements, AI models, publication, offline licensing, and safeguards is available on the Architecture and security page.
Review DataFlow components, access controls, how AI works, and network requirements.