Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

Supporting different component variations within same app codebase to be picked up by an IMS Org



The use case is that we want to use the same firefly app code base to have multiple variations of components and pages. This app will be deployed to many  organizations and a specific variation should be picked up by a particular IMS Organization. The expectation is similar to multi-tenancy (though it will be deployed on different servers) OR multi-site management where component/ page is picked up from specific site folder if it is present otherwise from common folder (inheritance model with dynamic routing & dynamic component includes)


So we want the code structure to be like:

- web-src

     - src

          - components

                - common

                     - component1

                     - component2

                - Org1 variation

                     - component2 (variation)

                - Org2

                     - component1 (variation)

          - pages

                - common

                     - page1

                     - page2

                - Org1 variation

                     - page2 (variation)

                - Org2

                     - page1 (variation)


Please suggest how this could be implemented.


2 Replies



Hi @shelly-goel, unfortunately, at this time there is no official guideline on multi-org deployment. That being said, you can always take the application codebase and deploy it to an org you have access to. 



Hi @shelly-goel - as Manik mentioned, this code structure is not supported by Project Firefly. 

You should consider modularizing your code in a way that commonly used functionalities should be available as (npm) libraries. They can then be used by different projects and apps. Npm libraries also allow you to manage the code releases with semantic versioning, so that there is no hard dependency for the client apps.

For the remaining pieces which vary by org / customer, they should be put in separate app code bases and deployed to the individual orgs, like what you have today.

This is the multi-tenant model that we are going towards.