When you use branches, different development teams can work without interfering with changes that other teams make in an application, even if multiple teams share one base ruleset. For example, Team A can develop service-level agreements for a case type while Team B fixes UI bugs in the application. When you provide separate branches for both teams, you minimize the risk of errors and work overwrites that might arise when both teams work on the same ruleset simultaneously.

To organize rules better during your development process, you can categorize rules into branch rulesets. Branch rulesets have the following characteristics:

• Branch rulesets are branched from rulesets in your application.
• Branch rulesets contain rules that are in active development in an associated branch.
• Branch rulesets have a naming convention that includes a ruleset ID, the word Branch, and a branch name, for example, SLAS_Branch_TeamABranch, where SLAS is a ruleset ID, Branch indicates a branch ruleset, and TeamABranch is a branch name.

Branching is especially useful in large development projects when multiple teams work simultaneously on the rules in an application, and members of one team view each others work, but isolate their development changes from other teams. Consequently, rule changes that one team makes do not affect the other teams until the changes are stable, conflicts are resolved, and the approval is granted to make the new improvements available to the entire development project team.

Branched development includes the following main tasks:

1. You create a development application that your team can use to develop new features. You create a development application by copying an existing application to ensure that the names of classes and rulesets remain unchanged.

   For more information, see Creating a development application.

2. You add development branches to the development application. Teams use branches to develop features independently.

   For more information, see Adding development branches to your application.

3. As a best practice, you create a branch review to ensure that rules in your branches are guardrail-compliant and meet your business objectives.

   For more information, see Branch reviews.

4. You make new features available in your application by merging changes from branches into a target ruleset. You now can resolve conflicts and address warnings that might arise among different branched versions of the same ruleset.

   For more information, see Merging branches into target rulesets.

For example: The following figure shows a sample scenario in which multiple development teams create service-level agreements (SLAs) and resolve UI bugs in a Loan Requests application. An administrator creates two development applications: one for the UI teams and one for the SLAs teams. In each application, the administrator creates two branches that contain branch rulesets. As a result, two teams can resolve UI bugs and two teams can develop SLA rules without affecting another team. After the development is complete, the administrator first reviews and then merges branches into target rulesets. As a result, the Loan Requests application includes new features from the simultaneous work of four development teams.