We’re Here to Help!!

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

Case Study: Informatica


The following document describes how Informatica has chosen to implement Flosum for Application Lifecycle management. The document first describes the team structure, sandbox strategy, release schedule and other business constraints before stepping through the flow.

Team structure

Informatica has about 15 to 20 Salesforce experts including Developers, Administrators, and Business Analysts responsible for delivering business applications. Informatica leverages external System Integrators to augment their own internal technical team. Since the external System Integrators are very well integrated in their own internal team, the rest of the document does not distinguish between the roles of the internal team members or the external system consultants.


The Informatica Salesforce team is responsible for delivering business applications to three organizations: Sales, Service, and Finance.

Release schedule

These business applications are delivered independently every month on a staggered schedule. For example, in the first week of each month the team delivers requirements for the Sales team, in the second week of the month they deliver requirements for the Service team, and in the third week of the month they deliver requirements for the Finance team. This staggered release schedule has a significant impact on their sandbox strategy and their application lifecycle management processes.

Sandbox strategy

As shown in the sandbox diagram, Informatica has four layers of sandbox structure:

At the lowest layer, each developer has his or her own sandbox for individual development.

In the next layer above, individual developer projects are merged for delivery to the Business Integration area. This is the ‘devtest’ organization for each of the business lines.

This is the place where individual developer changes are brought together to be reconciled and tested before those changes are committed to the Flosum Repository.

Once changes have been tested and committed to the Flosum Repository they can be pushed to the QA sandboxes for testing before being presented to the Business teams.

The Business teams review the new features in the UAT organization and approve them to be deployed to the Production organization or return them for re-work.

Application development workflow

The Development team makes use of Local Flosum to ensure that the development sandboxes are in sync with the Flosum Repository. This ensures that developers are working on the latest code base, and the changes between various developers are isolated from each other.


The numbers below correspond to the numbers of the arrows in the diagram above.

  1. Developers create a branch for each different feature or project. Once a developer finishes working on a particular feature, he or she uploads the code components to the respective branch in the main Flosum org.
  2. These individual feature branches are merged together from all the different features for that particular line of business into a master release branch for that line of business. (Example Dec-2016-Sales branch).

Alternative path: Please note that after step 1 developers could have directly committed the features to the repository. However, the features may not be tested well in the developer’s sandbox. Hence, the features are merged together into a “release branch” before committing to the repository.

  1. The master branch for a particular release, for a particular line of business, is deployed to the DevTest organization on the schedule for that particular line of business.

If any change is required as part of testing, the developers modify code components in their respective development organization, update the same branch, and then re-merge the changes with the same master branch.

  1. If everything looks great, the master branch is merged with the Repository and all the latest components are now available in that Repository.
  2. The developers for the other lines of business can download these changes to their own respective developer sandboxes.

For every commit to the repository, Flosum creates a Commit record which has the list of all the code components which were modified as part of that specific release.

  1. The QA team creates a patch from the Commit record.

Alternative path: Please note that the team could have decided to commit the code changes to the main Flosum repository after QA testing. This would cause delay in other development teams getting the changes done by the current team making the changes.

  1. This patch is deployed to the QA organization.
  2. If the test results are approved, the changes are deployed to the UAT org, and finally to the Production org.


The above is a summary of how Informatica has chosen to implement Flosum. There could be numerous variations to the above flow. Flosum is very flexible in adapting to your custom processes for application development.


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