DocumentationCommunityAcademyPlatformFeedback
STL Documentation

Dataflow

Why dataflow matters

When you start building a set of templates or a workflow, it’s worth spending time upfront on the data architecture and data flow.

A clear dataflow:

  • improves alignment across the team,
  • reduces technical debt,
  • prevents unnecessary dependencies, and
  • avoids costly refactors later.

Understand your data sources

Be explicit about where data comes from. Your sources will influence how you model the workflow and how you manage dependencies.

Typical sources include:

  • Period data
    • Account data
    • Transactions data
    • People data
    • Data coming from templates
      • Results
        • Accounts
        • Reconciliation templates
      • Custom fields
        • Period
        • Account
        • People
        • Template
  • Company data
  • Cross-company data
    • Ledger data
    • Data coming from templates

Decide where the data should live

Ask where user-entered or computed information should be stored.

Consider:

  • Is the information needed only to reconcile an account?
  • Is it only relevant inside a single reconciliation template?
  • Does it need to be reused elsewhere (now or later)?

Decide where the output goes

Clarify what happens to the result of a workflow or template.

Questions to answer:

  • Should the output become the default somewhere else?
  • Are you transforming data here that needs to be accessed in another place?
  • Will the output be exported?
    • PDF
    • (i)XBRL
    • Third-party integration
  • Should this output be reusable across companies?

Anticipate constraints and pitfalls

Identify likely technical challenges early, especially those that are expensive to fix later.

Common areas:

  • Dependency chains
    • Is there a risk of deep dependency levels (e.g. 4+), and caching issues?
  • Structured export requirements
    • Do you need an export schema with strict formatting rules?
  • Validations and checks
    • Are there rules you must validate against (data completeness, consistency, reconciled totals, etc.)?
  • Circular references
    • Could any part of the flow end up depending on its own output through another step?

Visualise the dataflow

Create a diagram that shows:

  • input sources,
  • transformations / computations, and
  • output destinations.

A simple visual makes development and later troubleshooting much easier, and helps with handover to other teams.

Design patterns