FAQ: Getting started and adoption
FAQ: Getting started and adoption
What is the fastest way to start using BusDK?
Start with workspace initialization, then run one end-to-end business scenario from the workflow pages. This gives you a concrete baseline repository layout, command behavior, and expected outputs before you customize anything.
Which docs should I read first if I only have one hour?
Read the overview page first, then the workflow index, then the module CLI reference index. This sequence gives you system purpose, operational flow, and exact command surfaces without forcing you into deep design material too early.
Should I migrate all legacy processes at once?
No. A phased migration is safer. Start from one workflow boundary, keep source evidence intact, and verify deterministic replay with bus replay before moving to the next area. BusDK’s modular design supports incremental adoption without requiring a single big cutover.
How do I train a team that currently uses spreadsheet-only processes?
Treat BusDK as a workflow standardization layer rather than a replacement narrative. Keep familiar business steps, but run them through deterministic commands and tracked workspace datasets so review, replay, and audit evidence become consistent.
Can I use BusDK in CI from day one?
Yes. The CLI-first model is intended for non-interactive execution. Teams typically start local, then promote validated .bus scripts into CI so the same commands run in both environments.
How should we choose which module to adopt first?
Choose the module that closes the highest-risk manual gap in your current process. For many teams this is journal, invoice, bank, or reconciliation flow. The module reference pages and feature table help map use cases to module surfaces.
How do we know an adoption step is complete?
Treat completion as evidence-based. A step is complete when command outputs are reproducible from declared inputs, review checkpoints are documented, and the workflow can be replayed with bus replay and verified with bus validate without hidden manual decisions.
How do we avoid over-customizing too early?
Use defaults first and postpone custom extensions until baseline flows are stable. BusDK supports extensibility, but early over-customization increases migration complexity and makes root-cause analysis harder.