The Environments page lists all your development mode applications in the Applications column. Apps that have been published to Stage will now be eligible to be published to production.

Steps to publish to production:

1. Navigate to the  Environments  under  Deploy  section.
   

   

2. Click Publish button in the top-right corner and choose  Publish to production  option.
   

   

3. In the Versions page a list of versions apps published to stage will be listed. Each package of apps and their changes that have been published to Stage at one instance is called a Version. Select the versions that have to be published to Production. You can select any number of versions, but the count of components in all versions combined cannot exceed 800.
   

   

   Note:
   

   • The count of the components in the selected versions is displayed in the bottom-left corner.
   • The search bar can be used to search for the required package.
   • The filter option lets you filter packages based on apps. For example, you can filter the packages using Application 1, and only those packages will be listed that contain Application 1.
   • Dependent versions are selected by default. If user does not have access to any of the selected app they will not be able to proceed.
4. Next the  Version  page will be displayed. Under the Publish Options section, you can either choose to publish immediately using the  Publish Now  option, or choose to schedule it at a required time using  Publish Later  option.
   

   

5. Select users to send  email notifications . The admins and developers of the application are listed here, and a maximum of three users can be selected.
6. Before the changes are published, a few validations are performed to ensure the publishing process is successful.
   
   • Duplicate records - To check if a field with "No duplicate values" property contains duplicate values in the Production environment. Example: Let's say an application is published to Production and a user adds duplicate values to a field. At this point, the field can accept duplicate values because the "No duplicate values" property is not selected yet. However, we then edit the app and select the "No duplicate values" property field and publish the change to Production again. This can now create a conflict, as the field already contains duplicate values, but now has a property that restricts duplicate values. In this case, we have to first remove the duplicate values, then click Validate to be able to proceed.
   • Data Loss - This is a warning that appears when a component is deleted and this change is published to Production. This is to alert users that this will also remove any related data in the Production environment when the change is published. Example: Let's say an application is published to Production and customers add entries in a form. We then edit the app and delete the form and publish this change to Production again. This will result in the deletion of all the entries made to the form in the Production environment (live data).
   • Permission - This is a warning that appears when a profile or a role has been deleted and this change is published to Production. The warning informs users that the deleted profile or role is mapped to the new one as specified during the deletion.
   • Post Publish - This informs users that the publishing process may take additional time when encryption or formula field changes are made that result in consuming more time besides the publishing time.
7. Click  Publish .
8. The publishing process will be initiated.
   

   

9. In the environments page, the status of the application under Production section will be  V{} in progress.
   

   

10. Once the publishing process is complete, the Production version of the app will be listed.
    

    

Locking mechanism during Publish

User collision scenarios during Publish

Related Links

• Understand Environments
• Adding apps to environment
• Publish to stage
• Environment locking mechanism