A Short Guide to Naming Automation Components
Large Make scenarios are easier to maintain when workflow logic is split into named components with clear inputs, outputs, and responsibility.
Read moreAbout - I build integrations and applications with the workflow in mind.
I’m Dusti Johnson, a CRM Integration Developer and Computer Information Science student at Washburn University. My work combines Make-based automation, CRM data flow, APIs, webhooks, and application development.
In my current role, I focus on building and maintaining automated workflows that support internal teams and advisor-facing technology. That means understanding requirements, mapping fields carefully, configuring integrations, testing in sandboxes, monitoring for failures, and documenting how each workflow behaves.
I also build software outside of CRM work: Next.js and TypeScript demos, SQL-backed features, Java research tools, and some mobile app projects. My background includes full-stack volunteer development at Center for Supportive Communities, faculty-mentored research at Washburn, and hands-on process troubleshooting in manufacturing.
- CRM integration and automation
- 01
- TypeScript and SQL-backed applications
- 02
- Research, documentation, and support
- 03
I like work where systems, data, and people have to line up.
Integration work rewards the same habits I value in application development: understand the workflow, make the data path explicit, test before production, and document the logic so the next person can trust it.
- Automation and integration. Designing Make scenarios, API and webhook flows, field mappings, sandbox tests, and troubleshooting paths for CRM-connected systems.
- Application development. Building Next.js, TypeScript, MySQL, MariaDB, Java, and SQL-backed projects with practical interfaces, clear data models, and reliable behavior.
- Clear communication. Translating technical work into requirements, acceptance criteria, documentation, and explanations that non-technical stakeholders can act on.
Recent writing
Practical notes on workflow logic, maintainability, documentation, and the engineering habits that keep systems understandable.
What ER Diagrams Clarify Before Code Exists
A good ER diagram makes entities, relationships, and ownership visible before those assumptions harden into application code.
Read moreHave a workflow or integration problem worth talking through?
I’m interested in Make automations, CRM data flows, practical application work, and teams that care about reliable systems.