From Solution Builder > Version Control, go to Active Branches page and click Add New.

In the side panel, enter the name of the branch and description and click Save.

It is good practice to set the name of a branch as something that describes the task that you are doing. For example, “Task side panel”.

Open the side panel and click Open Branch. If you were previously in that branch, click Switch Branch on the side panel to enter the branch.

From the main page, click on Edit row action to see details of the newly created branch. In the User Access tab, users can verify who is in their branch and the Branch Owner. Whoever creates the Branch is the Branch Owner by default.

Once you are in a branch, the status of your current branch in the Main grid of Active Branches is Active (Current).

A user can make any changes to branchable models now that the user is in a branch.

	Branch Size
	It is good practice to make each branch a small or manageable size of work (i.e., one page or one workflow). Do not create one branch and make an entire solution implementation in that branch.

From Solution Builder > Version Control, go to Active Branches page and click on the edit row action of a branch.

Depending on your role, you can:

1. Solution Developer: Only view the User Access side panel tab. You cannot add users to a branch or change its branch owner.

2. Solution Admin: Select a Branch Owner from a list and add new team members as part of the branch.

   	Branch Members
   	When you add a user to a branch, you will be notified in the web. You will now be allowed to switch into that branch when you want.

When a user is assigned to a branch, the user receives a notification via email and web.

The minimum number of users in a branch is 1. Only the Branch Owner is mandatory for a branch to exist.

From Solution Builder > Version Control, go to Active Branches page.

Select a branch that you want to enter and click on the edit row action.

From the side panel, select Switch Branch.

From Solution Builder > Version Control, go to Active Branches page.

Select your current active branch, which you want to request a merge/discard. You must be a branch owner to see the Actions list.

In the side panel, select either from the Actions list:

When a Branch Owner requests to merge/discard, a branch user:

1. Receives notification on the web.

2. Is removed from the branch.

3. Enters another branch by creating or switching to a branch to continue working.

From Solution Builder > Version Control, go to Active Branches page.

On the main grid, check your current branch status. If it is Update Available, there is an update available from Master that you need to pull from.

In the edit side panel, click Upgrade From Master.

1. Conflicts identified: Likely caused by changes to the same objects in master and in your branch. You will be prompted to resolve these conflicts by opening Merge Assistant.

2. No conflicts: Your branch is updated with the latest Master version and status of the branch is now Updated.

Once conflicts are resolved (if any) and a branch is updated, the Branch Owner can now proceed with the Merge or Discard request.

From Solution Builder > Version Control, go to Open Branches page. This page has all the branches that have been requested to merge/discard.

Open the edit side panel of a branch that you want to review and click Open Merge Assistant. The Merge Assistant identifies all the solution objects in that branch that were newly created, changed, deleted, or have conflicts.

In the Merge Assistant page, Solution Admin can:

If one object is rejected, Solution Admin must decline the whole branch. A declined branch is sent back to the Active Branches' data grid.

Only if all objects are approved, Solution Admin can proceed with merging the branch.

From Solution Builder > Version Control, go to Open Branches page. This page has all the branches that have been requested to merge/discard.

Open the edit side panel of a branch that you want to review.

On the side panel, from the Approve or Reject list, select either:

From Solution Builder > Version Control, go to Active Branches page.

View branches with status Merge Declined or Discard declined.

Open the edit side panel to view the rejection reasons.

To start working on the branch again, a branch user can either:

From the main page, click Add New.

Fill in General Information and Solution Configurations of the Bundle and click Save. The Bundle will be in "Draft" status.

Add solution objects to the Solution Bundle by selecting from the drop-down and adding objects to the table.

To view all the added objects, select View All.

To Delete Solution Objects, select from drop-down, hover over the record and click delete.

Once all objects needed for the bundle is added, "Publish" the bundle

Once the bundle is ready to be Deployed, Save and Deploy the bundle.

To make your bundle available on your target organization's app store, enter the source org and corresponding credentials within Org Config > External Systems.

For example, FSE is made available in the Z2store source org. Include the following as a row in External Systems > z2store record

1. "appStoreServer": "https://ramanlab.zinier.com",

   "orgId": "sourceorgname",

   "loginId": "useridhere",

   "password": "passwordhere"

In your target organization, go to App Stores.

Select the Solution Bundle you created and open the side panel.

Click Install to close the side panel.

Status of the bundle in the app store will change from "Available" to "Installed".

In your target organization, go to App Stores

Select the Solution Bundle with status "Upgrade Available" and open the side panel

Click on "Upgrade App"

If there are conflicts between the current solution in the target organization and the bundle to be installed, you will be prompted to go to the "Upgrade Assistant". For more information about conflicts and conflict resolution when installing or upgrading solution bundles, go to Solution Bundle FAQ

In Upgrade Assistant, Solution Admin can view the JSON code of each solution object in which a conflict is identified, make changes and merge the updated code.

Solution Admin can choose to override the conflicts in the target org with source org code, retain target org code OR make changes to merge the two.

Once all the conflicts have been resolved, solution admin can click on Upgrade to install the now modified bundle into the target organization.

In Zinier, go to Solution Builder > Sandbox and click Add New.

On the Sandbox page, enter the sandbox information which includes the Name and Org ID.

Enter the Super Admin information which includes the Name and Email. A Super Admin is the user who receives the invitation for the Sandbox org.

Select the Sandbox server. This will be the server the sandbox will be created in.

Click Save and Continue.

In the Sandbox Objects section, click Add New. Sandbox Objects are transactional data or seed data from the production org which can be migrated in the sandbox org.

Click Save.

The status of the newly created sandbox is Queued. Once the sandbox creation is successful, the status changes to Installed.

From the Solution Builder > Sandbox page, click the edit row action of the sandbox org that you want to import. The sandbox that you want to import must have the status Ready for Import.

From the Actions list, select Prepare for Import. This action preps your sandbox for import into Production. The status of the sandbox will change to "In Progress." In this status, the user cannot do any action on the sandbox.

Once "Prepare for Import" is successful, the status will change to "Ready for import"

As the status changes, user can open the edit row action, click the Actions list and select Import. This will import your sandbox into the production org. It is important to ensure that proper testing has been done before importing the changes in production.

The sandbox status will change to "In Progress" Once the Import is successful, the sandbox status will change to "Installed" This process may take a few minutes.

Once Installed, changes from Sandbox will be deployed in Production.

When there is a versioning conflict between the Sandbox and the Production environment, the user will be prompted to Refresh the sandbox before he can Import the Sandbox into Production. From the main page, open the edit row action, click on the Action dropdown and select "Refresh"

On Refresh, the system will check if there are any conflicts between Sandbox org and Production org. Conflicts arise when there are updates to the same record (same ID) in both the Sandbox org and the Production org.

If conflicts are found, the status of the sandbox will change to "Conflict".

1. The user must open the edit row action and click on "Resolve Conflicts". This will open the Conflict Manager where he can resolve and merge conflicts on each individual object.

2. Once the conflicts are resolved, the user can Import Sandbox into Production using the steps outlined in the previous section

If conflicts are not found, the status of the sandbox will change to "Available" after refreshing. The user is free to Import Sandbox into Production using the steps outlined in the previous section.

Reset is available for all statuses except for In Progress.

From the main page, click on the edit row action. Click on the Actions Dropdown and click Reset. Warning : Reset will wipe out all existing Sandbox configurations. This may mean that ongoing development work in Sandbox org will be lost.

Once Reset is successful, the status of the sandbox will change to "Available" The sandbox org will be a fresh clone of Production Org.

Archive is available for all statuses except for "In Progress" and "Resolve Conflicts"

From the main page, click on the edit row action. Click on the Actions Dropdown and click Archive

Once Archive is successful, the status of the sandbox will change to "Archived" The super admin and any user of the sandbox org will not be able to log into the sandbox org anymore.