Development Environment Strategies

as you expand your integration portfolio to support new verticals and external platforms, the complexity of managing your codebase increases attempting to build and maintain integrations for multiple different external systems within a single development environment can quickly lead to namespace conflicts, accidental cross contamination of logic, and a confusing repository for your developers to manage this expansion effectively, tavio recommends a strict environment strategy that leverages the platform's isolation capabilities to keep your solutions clean and organized isolation by platform the solution centric approach for platform partners (e g , background check vendors, assessment providers), the goal is often to build a repeatable solution for a specific external platform and deploy it to many clients the best practice for managing this is to create a dedicated development environment for each target platform you support for example, if you are a background check vendor expanding from greenhouse to workday and ukg, you should provision separate environments such as greenhouse dev workday dev ukg dev this "solution centric" approach provides several advantages safety work being done to update the workday connector cannot accidentally break the logic in your greenhouse solution focus developers working in ukg dev see only the schemas, connections, and logic relevant to ukg, reducing cognitive load and configuration errors clean bundling when you are ready to distribute your solution, you can bundle the entire contents of workday dev knowing that it contains exactly what is needed for that specific integration, without extraneous code note for system integrator (si) partners if you are building repeatable, productized integrations, you should follow the solution centric model described above however, if you are building bespoke, custom integrations for specific clients, we recommend a client centric approach in this scenario, you should provision a dedicated development environment for each client (e g , acmecorp dev) to accommodate their unique, overlapping, or conflicting requirements without impacting other projects consistent naming conventions the primary benefit of isolating your development environments by platform is the ability to standardize your naming conventions because workday dev and icims dev are completely isolated from one another, you do not need to prefix your workflows with the system name to avoid conflicts instead, you may use identical, semantic naming conventions across all of your development environments for example, for a candidate sourcing use case, every environment could contain two workflows, one for pulling jobs data and another for creating applications for candidates whose profiles match the extracted jobs across all environments, regardless of the ats the sourcing vendor is connected to, those two workflows could be titled e g jobs extract and apply candidate the operational benefit this consistency dramatically simplifies the scale phase of your operation when your implementation specialists or support teams log into a customer's environment to deploy or troubleshoot a solution, they do not need to relearn the workflow names for every different ats or hris the jobs extract integration always performs the same business function, regardless of whether the underlying connector is talking to workday, oracle, or sap this uniformity reduces training time and accelerates issue resolution