We’re Here to Help!!

Find A Solution, Learn Best Practices & Get Support 24x7

Case Study: Company Training and Process Flow Documentation Example



This case study shows an example of how one of our clients (we'll refer to them as Company A throughout this document), chose to document their internal training and process flow of Flosum. It also outlines how they are integrating Flosum with Jira. 


This guide is intended to assist with the setup and use of the various Company A's IT SDLC tools required for Salesforce development. See the complete Process Flow; See Appendix A. The systems and applications involved with Salesforce development and deployment are:

  1. Salesforce – Production Org with 3 Full Sandboxes
  2. Flosum – CICD tool which ties all Salesforce Developer, Full, and Productions Orgs together
  3. JIRA – Agile Tool used to manage work items for the development team Company A IT uses Scrum methodology for organizing and completing work
  4. ServiceNow – Company A IT’s ITIL tool for ticketing and issue management; this tool is used for all production Change Requests Approvals
  5. DataMigrator – a Flosum tool that can move production data to Developer Orgs
  6. Service Rocket – a JIRA plugin that integrates JIRA to Salesforce
  7. Boomi – enterprise integration platform
  8. Confluence – wiki used to publish Salesforce deployment and release notes
  9. VSTS – external code repository
  10. Sonarqube + CodeScan – code analysis tool; CodeScan is a plugin for Sonarqube specifically for Apex code analysis.
  11. Selenium – automated unit testing tools


Commonly used by Company A IT Acronyms related to Salesforce Development.

SN – SerivceNow
CICD – Continuous Integration Continuous Deployment VSTS – Visual Studio Team System
ALM – Application Lifecycle Management JIRA – Company A IT Agiletool
BA – Business Analyst
CAB – Change Approval Board
SFDC – SalesForce Dot Com (Salesforce.com) SDLC – Software Development Life Cycle
Company A IT – Company A IT Information Technology UAT – User Acceptance Testing


People who regular participate in the Salesforce Development process:

Product Owner – provides direction and overall vision for the Salesforce system
Project Manager – organizes larger scopes of work; provides timelines; business expectations Business Analyst – works with the business to understand required changes
Scrum Master – leads the prioritization & organization of work into sprints
Architect – designs the technical work to be completed Developer – builds the system to work as designed
Release Manager – oversees the movement of code into production Business User – request changes/features & tests completed work Change Approver – board of advisors who review change requests
Governance Team – verifies the defined development processes are followed Manager – Reviews system to ensure efficient and effective

System Overview


         *"Patches" have since been renamed to be called "Deployments"

Developer Sandboxes

At the beginning of a development cycle the sandbox used for new code or configuration should contain the current version of the code and configuration from the Production org. There are two sources where this data can originate: Sandbox Creation/Refresh from Production or Pulled from Repository 2 (gold copy) in Flosum. It is recommended that a new Sandbox or refreshed Sandbox are used. However, depending on the circumstance it may be necessary for the developer to get production code from the repository.

Sandbox Refresh or Creation



A sandbox refresh or the creation of a new developer sandbox can be completed from the production org by a production administrator. Company A IT currently has 130 developer sandboxes available so developers may choose to have up to 5 developer orgs at one time. A new sandbox or a refresh requires the following steps:

  1. New or refreshed sandbox is created by a Salesforce Administrator in P1 Production. How to Create or Refresh a Salesforce Sandbox; See Appendix B
  2. In P1 Production push data to the newly created or refreshed sandbox via DataMigrator. How to Create Data in Developer Sandbox with DataMigrator; See Appendix C
  3. Connect or Re-Authenticate Sandbox to Flosum

How to Connect Developer Sandbox to Flosum; See Appendix D

  1. (Optional) Install and Connect Local Flosum in Developer Sandbox How to setup Local Flosum in a Developer Sandbox; See Appendix E


Pull Code from Repository

 *"Patches" have since been renamed to be called "Deployments"

In certain situations, a developer may not have the option to refresh a sandbox because it contains code and configuration that is still under development. This situation occurs when code and config changes are unexpectedly delayed and only a portion of the changes are moved, or all changes are delayed.

When this happens, a developer cannot refresh the sandbox to get a current copy of production. Creating a new sandbox (recommended) may not be the best option if there are future development dependencies on code currently in the Developer Sandbox but not yet pushed to production. To ensure the developer has the latest copy of code and configuration use the following process to retrieve latest code:

Option 1: Use Local Flosum

  1. From the Developer Sandbox, navigate to the Local Flosum ‘Settings’ tab and ensure the

Repository 2 (gold copy) is selected.

  1. Navigate to the Remote Repository tab, select a date to retrieve changes
  2. Apply appropriate changes to Local Org Local Flosum User Guide; See Appendix F

Option 2: Use a Patch

  1. From Flosum build a patch from Repository 2 for the needed code/config
  2. Deploy that patch to the developer sandbox


Integrated Development Environment (IDE)

Use of an IDE is recommended but not required. IDE’s should be attached to Developer Sandboxes only. Company A IT does not have a preferred or recommended IDE, developers are free to use their IDE of choice: Sublime, Eclipse, VS Code, Developer Console, Cloud9, etc..

Atlassian JIRA

JIRA is Company A Corporate IT’s agile tool for organizing work in the Scrum methodology. JIRA is the system of record for User Stories (work items) for tracking requirements, communications, and interactions between the Project Managers, Product Owners, Business Analyst, and Developers. JIRA has an integration with Flosum to create branches where code and configuration changes related to the User Story are collected prior to deployment. JIRA User Story information is carried forward to the repository commit and patch. The Jira information on the Patch is later included in reports for production deployments to support the governance team.

 *"Patches" have since been renamed to be called "Deployments"

  1. A JIRA User Story is groomed, prioritized, added to a sprint, and assigned to a developer
  2. Developer determine if Code or Configuration will be needed to fulfill the acceptance criteria
  3. If yes, in JIRA the Developer creates a Flosum Branch through ‘Manage Application Links’

Create Flosum Branch from JIRA User Story; Appendix G

  1. JIRA information on the Branch in Flosum is kept in-sync with changes to the story in JIRA
  2. When a check to the repository from the Branch is made the JIRA information is pushed to the repository ‘Commit’ record
  1. When a ‘Deployment’ is created from the Branch the JIRA information is put on the Patch
  2. Reporting is available to understand which JIRA User Story is associated to a code or configuration change.

Note: When the User Story in JIRA is closed it has no impact on the Flosum Branch



Flosum is Company A IT's ALM tool for enabling continuous integration and continuous deployment (CICD) for Salesforce development. Flosum is build 100% on Salesforce (separate enterprise SFDC org) and provides a familiar and consistent UI for developers. Flosum was chosen as Company A IT tool because of it’s full range of features contained in a single tool; we preferred this to having many tools integrated together to accomplish the same capabilities within Flosum. It is intended that developers work in a single tool (Flosum) to accomplish the CICD process. Some of the features of Flosum Company A IT is taking advantage of is Version Control, Patches, Conflict Checking, Governance, one-click Rollbacks, support for all Metadata & Code changes, Org Comparison, and 360° Communication.


Anonymous IT uses Flosum as its primary hub for Salesforce org to org interactions. Developers should move

all code through the development process via Flosum Patches for consistency and governance purposes. Flosum provides many time saving features that will be obvious as you review each of the below sections. Company A IT's Salesforce development team has grown to 20+ developers and following the processes details in the document and using the Flosum tools has reduced the number of issues introduced to production and the amount of work required by multiple teams.


Naming Conventions

In Flosum we use a naming convention for a variety of objects to ensure the record is easy to find and select in picklists. The following naming convention must be followed; records created with an improper name will be deleted from the system.





Snapshots are created ad-hoc by the developer and should be named by the convention below.


20170818-CC-ITCRM 6-Flosum Setup & Config

Date(YYYYMMDD)-Developer’s Initials-JIRA User Story ID or Project-Your Description


When creating a branch from JIRA the system will create the branch record and populate the name with the correct format. Names are not editable for system generated branches. When creating a branch manually in Flosum follow the pattern below.


System generated from JIRA:


Manually created branches have the option of adding a description:

20180302-CC-CISC-3-ServiceCloud Web API

Date(YYYYMMDD)-Developer’s Initials-JIRA User Story ID or Project-Your Description


Creating a commit to the repository should following the convention below.

20160818-CC-MicroEdge-Project Creation Bug

Date(YYYYMMDD)-Developer’s Initials-JIRA User Story ID or Project-Your Description


When the deployment is originally created it will follow the same pattern as the snapshot, branch, & commit (Date(YYYYMMDD)-Developer’s Initials-JIRA User Story ID or Project-Your Description).


While the deployment is being deployed to various sandboxes no change to the deployment name is required. When the deployment is ready to be pushed to production one of two changes are required. If the change is configuration only and does not required change management approval in SN (see What Requires Change Approval; Appendix H) ‘CHGConfigOnly’ must be added to the patch name. If change management approval is required in SN, the Change Number (CHG3051548) for the approval is required. Follow the below naming convention.


Deployment creation naming:

20160818-CC-ITCRM 271-Install Xactly

Date(YYYYMMDD)-Developer’s Initials-JIRA User Story ID or Project-Your Description

Deployment ready for production – no Change Approval Required:

20160818-CC-CHGConfigOnly-ITCRM 271-Install Xactly

Date(YYYYMMDD)-Developer’s Initials-ChangeID-JIRA User Story ID or Project-Your Description

Deployment ready for production – Change Approval Required

20160818-CC-CHG3051548-ITCRM 271-Install Xactly

Date(YYYYMMDD)-Developer’s Initials-ChangeID-JIRA User Story ID or Project-Your Description

Note: Failure to follow the above will result in the a governance team member email ask you to explain the deployment (reporting relies on this nomenclature).


Flosum has a tab that represents all the connected SFDC sandboxes and the production org. In order for a developer sandbox, full sandbox, partial sandbox or production instance to use Flosum it must be connected on the Orgs tab.


 *"Patches" have since been renamed to be called "Deployments"


The Orgs tab is the window into each of the orgs connected to Flosum and enables monitoring the progress of activities across these orgs. We monitor details of deployments, commits, branches and other activities.

From the Orgs Tab you can use the New button to connect your orgs to Flosum. <Click> How to Connect Developer Sandbox to Flosum; Appendix D. Orgs should follow this naming convention:


Developer Orgs – ‘Developer [Developer’s Org Name]

Admin Orgs – ‘Administrator [Admin Org Name]

Full, Partial Sandboxes & Production – ‘Anonymous IT [Org Name]

Once connected you can drill down into each of the connected orgs to:


  1. Create and compare snapshots of your orgs
  2. Schedule automated test execution
  3. Assign permissions for org access
  4. Initiate Audit activities
  5. View detailed Deployment history for all deployment activities, whether from Snapshot or Deployment
  6. View detailed log information for all activities


The Snapshot allows us to capture the state of an Org at any point in time. We use Snapshots to pull code from the Developer’s org (or any org) to be placed into a branch or deployment for moving items between orgs.


Snapshots can be used:

  1. To pull metadata/code/config from the developer’s org for move to a branch
  2. To pull metadata/code/config from the developer’s org for move to another org
  3. To pull metadata/code/config from a full or partial sandbox for move to a developer org
  4. To create a back up of metadata/code/config for a sandbox that is refreshed
  5. Etc…

For example, if a developer has been working on a feature/change for the last two days, and wants to identify the changes they have made over that period, this is the optimal way to retrieve changes from the source org. You can pull metadata/code/config based on a variety of criteria. How to create a Flosum Snapshot & Add to Branch; see Appendix J.



The branch allows for software to be developed in parallel enabling developers to isolate changes without destabilizing the code base. When a new branch is created (either manually or from JIRA), the branch is empty. When the developer modifies the code during the development cycle, the modified components are committed (pull - from snapshot, push – from Local Flosum) to the branch. After the code is tested, the branch can be committed to the repository and a patch can be created to move the code forward to another org.


Flosum provides a Version Control system. The primary components of the system are the Repository and Branches. When checking to a branch Flosum inspects the metadata/code/config for conflict and versions the items checked-in. This allows two developers to work out of the same branch and ensure conflicts are resolved before a new version is allowed in. The same is true for Repository commits. The metadata/code/config are inspected for conflicts and a resolution must be provided before the code is checked in to the Repository and versioned.

Branching also generally implies the ability to later merge or integrate changes back onto the parent branch. Flosum allows developers to keep multiple versions of the code at the branch level.

From the Branches page, click on a Branch link to be taken to the Branch Detail page for that branch. Here you will be able to:

  1. Commit to Repository
  2. Transfer to Patch
  3. Merge Branch


A Flosum Repository is the central database for tracking changes to the development orgs. The Repository is often referred to as the main line, gold, trunk, master branch, or head of Version Control. When using Version Control, the Flosum Repository holds the most recent version of changes to code in development and production. All versions of the code are held in the Repository and a complete history log of each component is available. Company A IT has two Flosum repositories:

  1. Repository 1 (default)
  2. Repository 2 (gold)

Repository 1 is used for code that has passed unit testing by the developer in DEV and is ready to be submitted to a Patch, scanned, peer reviewed and moved to TEST org for UAT, Integration Testing, & Regression Testing. Repository 2 is checked to when a patch is being pushed to Production. This repo holds the copy of production code and is representative of production code/config. How to Check Component to the Repository; see Appendix I.

Comparing & Conflict Resolution

There are number of tools in Flosum to compare code/metadata and resolve conflicts. You can compare code from one org to another org. The system will compare code within a branch or the repository during a check-in.

Org-to-Org Comparison

Snapshot comparison is a way for you to compare changes across organizations. Flosum’s comparison

solution provides the following capabilities:

  1. Compare the same organization at different points in time
  2. Compare two different organizations
  3. Compare side-by-side declarative as well as programmatic components
  4. Compare multiple different components of a given metadata type one after the other

Conflict Resolution

When changes are committed to a Branch or Repository conflict checking occurs and the developer is presented with a screen that has three sections:

    1. Components that have conflicts – components that have conflict with another developer’s changes
    2. Components that are safe to commit – component with no conflicts
    3. Components that will not be committed – component has an identical component in the branch or repository

When a conflict is found the conflicting code or metadata can be reviewed from Flosum with a line-by- line view. Components with a conflict must be resolved prior to check into the branch or repository.

Note: when using Local Flosum the conflict can be resolved directly in the tool; all other conflicts must be resolved in the sandbox and re-submitted for check-in to the branch or repository.



Deployments provide a way for a developer to define a set of changes to be moved from one organization to another. Using deployments, we can deploy relevant changes to any Flosum connected organization. Deployments have many advantages over traditional change sets: we can deploy all metadata components together; create a single deployment and deploy it to multiple orgs; add, remove, and update component in same deployment; all metadata types are supported, move code to another org with one click and rollback the change with a single click, add more advanced items like Pre-Destructive and Post-Destructive changes.

Deployment Example:


  *"Patches" have since been renamed to be called "Deployments"

Flosum allows deployments to be created from a variety of sources: Branch, Repository, Commit, or Snapshot. Developers in almost all cases should be creating a Deployment from a Branch. Deployments should never be directly created from a snapshot. How to Create a Flosum Deployment; see Appendix K.

Peer Reviews

Prior to code moving to our SFDC TEST org it must be checked into Repository 1 (default), conflicts resolved, submitted for code analysis scanning, and peer reviewed. Peer reviews consist of two developers reviewing code/configuration changes and checking for the following:

  1. Company A  Code Standards
  2. Best Practices are Followed
  3. Code Coverage is 80% or above
  4. Code Analysis Score thresholds are met

When the above standards are met the peer review form in Flosum is completed and the Deployment may proceed to be deployed to TEST. If UAT is not passed and changing are required a second review is required for the modified components and second Peer Review form should be completed.


When a feature or change is complete and has passed UAT a deployment can be requested. Deployments are initial requested on the JIRA User Story. The developer or release manager must complete the following to be approved for a production deployment.

If a Change Approval is required:


  1. Complete a Service Now Change Request form with the required information Sample Change Request; see Appendix L
    1. JIRAUserStoryID
    2. ChangeSummary
    3. List ofComponents
    4. Who Developed theFeature/Change?
    5. List of UATtesters
    6. LinktoJIRAUserStory
    7. Link to FlosumDeployment
  2. Developer or Release manager must attend the change management meeting and present the change(s) to the CAB
  3. In Flosum Update the Deployment name to include the SN CHG Id
  4. In Flosum Validate the Deployment against Production
  5. In Flosum fill out the Release Notes on the Deployment
  6. At the scheduled deployment time the Release Manager will push the Deployment (attended or unattended) to production
  7. Post deployment steps are performed by the Developer or Release Manager
  8. Users verify the production change is working as expected.If a Change Approval is not required:
  1. In Flosum Update the Deployment name to include the ‘CHGConfigOnly’
  2. In Flosum Validate the Deployment against Production
  3. In Flosum fill out the Release Notes on the Deployment
  4. At the Developers requested time the Release Manager deploys the Deployment (attended or unattended) to production
  5. Post deployment steps are performed by the Developer or Release Manager
  6. Users verify the production change is working as expected.

 Change Management Meeting occur twice a week on Monday and Wednesday.



Flosum has been integrated with several systems that provide additional functionality to the SDLC.


  1. Boomi – enterprise integration platform; when production deployments occur Boomi picks up the Release Notes and sends them to Confluence and pushes a chatter message to SFDC

production group ‘Application Delivery Deployments’

  1. Service Rocket – JIRA plugin that provides point-n-click integration to SFDC
  2. Heroku/Git – Flosum pushes code checked-in to a repository to a VSTS repository, this is accomplished through a Heroku integration using Git

Local Flosum

Local Flosum is an optional tool provided by Flosum to improve the Developer experience. Local Flosum is a small app that installs directly into your developer sandbox. From there, it facilitates communication between sandbox, Branches and Repository. With Local Flosum, developers get access to the latest repository code without having to refresh their sandboxes.

Local Flosum recognizes the components that are changing in each developer sandbox. Based on the history of those changes, Flosum can greatly improve the algorithms used to detect code changes.


  1. Enables earlier and more precise code conflict detection
  2. Improves and automates code merges
  3. Gives Developers more control over their integration processes
  4. Allows developers to easily sync sandboxes with the Flosum Repository
    1. Pull changes from Repository to developer sandbox
    2. Push changes to from developer sandbox to the branch without leaving the sandbox


Local Flosum creates tighter integration between sandbox and repository, it helps detect conflicts earlier in the development cycle.

Appendix A – Process Flow


 *"Patches" have since been renamed to be called "Deployments"


Appendix B - How to Create or Refresh a Salesforce Sandbox

From Setup, enter Sandboxes in the Quick Find box, then select Sandboxes. Create a New Sandbox

  1. Click New Sandbox.
  2. Enter a name (10 characters or fewer) and description for the sandbox.


It is recommended that you choose a name that:


    1. Reflects the purpose of this sandbox, or associates to a person. (Example: TEST or [LastName] of Developer)
    2. Has only a few characters, because Salesforce appends the sandbox name to usernames on user records in the sandbox environment. Names with fewer characters make sandbox logins easier to type.


 3. Select the type of sandbox you want.

Create a Sandbox


4. Click Next and Create.


Refresh a Sandbox


  1. Locate the sandbox to be refreshed.
  2. Click the Refresh link



  1. Select the type of sandbox



  • Click Next and Create



Appendix C - How to Create Data in a Developer Sandbox with DataMigrator

In P1 Production, from the App dropdown or selector choose Dataplier

1. Click Executions tab

2. Click New

3. Leave the default Execution Name & select ‘DMG Base Records Migration’ Execution Sequence


 4. Click Create

5. On the Connect dialog box provide your developer sandbox credentials


6. Click Log In

7. The execution should complete without errors and display the number of records moved


Repeat the above steps to add additional datasets to the developer sandbox.


Appendix D - How to Connect Developer Sandbox to Flosum

In Flosum org:


    1. Go to the Orgs tab
    2. Click on the New button in the Recent Orgs section
    3. Enter the Organization Name (follow naming convention)



      • Developer Orgs – ‘Developer [Developer’s Org Name]
      • Admin Orgs – ‘Administrator [Admin Org Name]
      • Full, Partial Sandboxes & Production – ‘Anonymous [Org Name]
    • Choose the Organization Type
    • Click on Authorize
    • When the Salesforce login screen is presented, enter the credentials of the sandbox or other org you are connecting to Flosum. (for Production and Full Test Sandboxes the Flosum Deployment service user should be used)
    • You will then be redirected back to your Flosum org with the newly registered org visible in the Recent Orgs list.


Repeat to register more orgs.

The demo below walks you through these steps. https://support.flosum.com/hc/article_attachments/115008317448/ConnectYourOrgs.gif

If you see the below error when trying to create a snapshot or perform other activities against your sandbox:



  1. Click Edit on the org and follow steps 5 & 6

Appendix E - How to setup Local Flosum in a Developer Sandbox

Login to your Sandbox

  1. Append the following after my domain ‘/packaging/installPackage.apexp?p0=04t360000016Ojn’ Example: https://anonymous-ttec.cs19.my.salesforce.com/packaging/installPackage.apexp? p0=04t360000016Ojn

 2. Click Install

3. Local Flosum leverages the built-in OAuth security mechanisms of Salesforce for org access. Local Flosum uses a Salesforce Connected App to provide OAuth single-sign on security when connecting to your main Flosum org.

This means that Flosum doesn’t store, and can’t retrieve, any passwords. This is something to keep in mind when changing your org usernames and passwords.

Once installed, Flosum has done most of the work of creating your Connected App.

4. Click on your Local Flosum Settings tab to see the OAuth Settings & enter a name – click Create




Now wait 10 minutes…

 5. In the Register Flosum Org section click Authorize

6. Enter flosum.serviceuser@anonymous.com Login information & Allow Access

7. In the Select a Repository section select ‘Default’ repository and click Save

8. Now from the ‘Remote Repository’ tab you can pull in changes

9. From the ‘Local Workspace’ tab you can collect local changes and push them to a Branch in Flosum

See User Guide for more details: https://support.flosum.com/hc/en-us/articles/115003754248-Local-Flosum-User-Guide

Appendix F – Local Flosum

Local Flosum is a small Flosum app that installs directly into your developer sandbox. From there, it facilitates communication between sandbox, Branch and Repository. With Local Flosum, developers get access to the latest repository code without having to refresh their sandboxes.

User Guide



Appendix G - Create Flosum Branch from JIRA User Story

From the JIRA User Story


  1. This process must start from the JIRA User Story on a board configured for integration.
  2. On the user story select the 'ellipse' (...) or 'More' for additional menu option 
  3. Find "Manage Application Links" on the menu:


4. From the 'Manage Application Links' screen...select the 'Create new Branch from this issue' link under 'Operations':


5. You will now see a 'Flosum Branch' & Id under 'Remote System and Object Type':

Note: You can only create one linked branch per User Story or per Task - so if you have 5 development tasks under one user story, each development task could have it's own Flosum Branch if needed or you could have one Flosum Branch for the entire user story (recommended).



6. The Flosum Branch will be created with proper naming convention YYYYMMDD-Initials-UserStoryID:

Note: You cannot modify the Branch name if linked to a JIRA User Story or Task.

 picture1.png7. You will see a link on the User Story or Task page:


Appendix H -What Requires Change Approval?


Change Request Requirements - Flosum

Appendix I- How to Check Component to the Repository

From the Branch Tab in Flosum

Once changes have been captured in a Branch, they can be committed to the Repository:


      1. Navigate to Branches tab
      2. Select the branch containing the changes you want to commit
      3. Click Commit to Repository

The Commit to Repository: Status screen shows you the changes grouped into three sections:

  • Components that have conflicts
  • Components that are safe to commit
  • Components that will not be committed

Once conflicts have been resolved, the Commit to Repository button will be enabled and you will be able to commit those changes. The flow is:

    • Developer Org
    • Branch
    • Repository 1
    • Patch



Appendix J - How to create a Flosum Snapshot & Add to Branch

  1. Log into the Flosum organization.
  2. Go to Orgs Tab.
  3. Select the source organization (org where the changes have been made).
  4. Click on Create Snapshots.
  5. Specify an appropriate Snapshot Name (follow naming convention).
  6. Specify ‘Retrieve changes in the last’ # of ‘days’
  7. Apply filters to limit the number of components returned:


 8. Click Create Snapshot

9. Wait for several minutes. Do not close the browser window 

10. Once you are redirected to the Snapshot detail page you may refresh until the Is Complete? checkbox is ‘True’


 11. When Snapshot is complete you can click Commit to Branch

 12. On the ‘Commit to Branch: Select Components’ screen, use the lookup to find your Branch

 13. Select the Components to Commit and Click Continue Commit to Branch


  On the ‘Commit to Branch: Status’ page view any conflicts that need to be resolved and click Continue Commit to Branch

 15. Confirm your updated component has been added to the Branch


The flow is

  • Developer Org
  • Branch
  • Repository 1
  • Patch

The Snapshot on the org ‘pulls’ components from the Developer Org for collection in the Branch. Local Flosum allows you to do the same process but ‘push’ changes to the Branch.


Appendix K - How to Create a Flosum Patch

From the Branches Tab in Flosum

1. Locate the Branch with changes to be moved to a Patch

2. Click Transfer to Patch

3. Using the naming convention provide a Patch Name or add to an existing Branch

4. Select the components to Transfer To Patch


5. Click Transfer To Patch

The flow is:

  • Developer Org
  • Branch
  • Repository 1
  • Patch


Once a Patch is created it can be re-used to deploy to any connected org. Patch carries with it the JIRA information from the branch.


Appendix L - Service Now Change Request

Sample Change Request


  1. JIRA User Story ID
  2. Change Summary
  3. List of Components
  4. Who Developed the Feature/Change?
  5. List of UAT testers
  6. Link to JIRA User Story
  7. Link to Flosum Patch
  8. Scheduled Deployment Time


Print Friendly and PDF
Was this article helpful?
0 out of 0 found this helpful