1. Publishing applications in environments

1. Publish to stage: The changes in the application must first be published to the Stage environment for testing.
   
2. Publish to production: Once verified in the Stage environment, the application version can be published to Production.
   

1.1. Publish to stage

1. Navigate to the Environments section under Deploy.
   
2. Click the Publish button in the top-right corner and select Publish to Stage. The Select Apps page will appear, displaying all applications with the Changes Available status as cards.
   
3. Choose the applications to be published to stage and click Proceed. A maximum of three applications can be published at a time. 
   
   
   
   The Staging page will display with the list of application components modified in the development environment of that application.
   
   The changes will appear alongside visual indicators that highlight the nature of the changes. The Staging page makes use of three specific markers as follows:
   
   

   "Added"	-	A new change has been added to the component/ the component is new.
   "Modified"	-	An existing component has been modified.
   "Deleted"	-	A component has been deleted.

   Additional apps can also be added from this screen for publishing by clicking the ➕ icon, provided they contain changes with the Changes Available status.
   
4. Select the components you want to publish, such as forms, fields, and reports, then click Proceed.
   
Note:
1. If any of the selected components have dependencies (for example, a relationship through a lookup) with other components within the same app or across different apps, all related components must be published together.
   
2. A maximum of 800 components can be selected collectively for publishing to the stage environment, irrespective of the applications selected.
   
3. Users without permission to access to any of the dependent apps will not be able to proceed with publishing.
   
4. When a component is selected, any dependent components within the same application will be selected automatically. If dependencies exist in other applications, a prompt will appear, allowing you to select the relevant dependent app, as shown below.
   
5. Specify the Title and Description for the version in the Version Details page.
   
Info:  
1. Each set of applications and their associated changes that are published at a single instance is referred to as a Version. When multiple applications are selected for publishing to the stage environment, they are bundled together into one version package, sharing the same version details such as the title and description.
   
   For example, if you select two applications with different version numbers to publish to stage, they will still be packaged as a single version that contains both applications with their respective version numbers. When moving from stage to production, this entire version package must be published together, and the individual applications within that package cannot be published separately.
1. 
6. Select the version type as Major or Minor. Use a Major version for new features or significant changes, which increments the whole number (for example, V1.0 to V2.0). Use a Minor version for small updates or bug fixes, which increments the decimal part (for example, V1.0 to V1.1).
   If you change a minor version such as V1.2 to a Major type, it will be rounded up to the next whole number (V2.0).
   
7. Select users to receive email notifications after the application is published. The admins and developers of the application are listed here, and a maximum of three users can be selected.
   
   Before publishing, the application undergoes validation checks to ensure a smooth and error-free deployment. Learn more about these validations.
8. Click Publish to initiate the publishing process. During this process, the application will be temporarily locked in the development and stage environments to prevent any modifications. Learn more about application locking during the publish process.
   
1. When the application changes are being published, the application's status will be displayed under the Stage section in the environments page. Learn more about application statuses in environments.
   
2. Once the process is complete, the Stage version of the application will be listed with the status V{0} is published and ready for further testing or deployment.

Note: In case of any errors during the publish process, the status will be displayed as 'Error in publish'. Error details can be viewed by clicking the status.

1.2. Publish to production

1. Navigate to the Environments section under Deploy.
   
2. Click the Publish button in the top-right corner and select Production. A Select Version page will appear, displaying all the versions of the applications that are published to the stage environment.
   
Note: The value shown next to the Production (for example, “1/30”) indicates that there is currently one unpublished version package in Stage, out of 30 supported versions. Once this limit is reached, you must publish one or more versions to production before you can create additional versions in stage.

1. 
3. 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.
   
4. Select the preferred publish options in the Version page, you can either choose to publish immediately using the Publish Now option, or choose to schedule it at a required time using the Publish Later option.
   
5. Select users to receive email notifications after the application is published. The admins and developers of the application are listed here, and a maximum of three users can be selected.
   
   Before publishing, the application undergoes pre-validation checks to ensure a smooth and error-free deployment. Learn more about these validations.
6. Click Publish to initiate the publish process. During this process, the application will be temporarily locked in the production environment to prevent any modifications.  Learn more about application locking during the publish process
   
1. When the application is being published, the application's status will be displayed under the Production section in the environments page. Learn more about application statuses in environments.
   
2. Once the process is complete, the production version of the application will be listed and ready to be accessed.
    

2. Validations when publishing the application

1. Errors - Prevents publishing due to critical issues. You must resolve these issues before proceeding, such as duplicate records or maximum field length violations.
   
2. Warnings - Notifies you of potential issues but do not block publishing. You can proceed despite these warnings, such as data loss, permission changes, or post-publish impacts.
   

2.1. Errors

1. Duplicate records: This validation checks whether a field marked with the 'No duplicate values' property contains duplicates in the target environment. For example, an application is first published to stage without enabling the 'No duplicate values' property, allowing duplicate entries during testing in stage. Later, if the app is updated to enable this property and re-published to stage, a conflict occurs because the field already contains duplicates in the stage environment. To proceed, you must remove the duplicate values and click Validate again.
   
2. Max field length: This validation checks whether any field values in the target environment exceed the maximum character limit defined in the environment the application is being published from. For example, suppose an application is published to stage with a single line field that allows up to 10 characters. During testing, values of 10 characters are entered. Later, if the app is updated to restrict the field to five characters and republished, a conflict arises because existing values exceed the new limit. To proceed, you must shorten or remove those values and click Validate again.
   

2.2. Warnings

1. Data Loss: This warning appears when a component, such as a form, is deleted, and that change is published to the stage environment. It informs users that any related data will also be removed. For example, if an application is published to Stage and test entries are added to a form, and later the form is deleted and the change is published, all previously added entries in that form will be deleted.
   
2. Permission: This warning appears when a user profile or role has been deleted and the change is published to the Stage environment. It informs users that the deleted profile or role will be mapped to a new one, as specified during the deletion process.
   
3. Post Publish: This informs users that the publishing process may take additional time when changes involve encryption or formula fields, as these require extra processing time beyond the usual publishing duration.
   

3. Locking of application during publish

1. Locking on publishing to stage
   
2. Locking on publishing to production
   

3.1. Locking on publishing to stage

3.2. Locking on publishing to production

4. Point to note

1. Only the application that has been modified in the development environment with the status as Changes Available can be published.
   
2. If an application has dependencies within itself or with another application, the related components or dependent application must also be published together to ensure proper functioning.
   
3. Published application versions cannot be rolled back to earlier versions.
   
4. While selecting a version to publish to Stage or Production, ensure that the total number of components across all selected versions does not exceed 800.
   
5. Applications installed from the marketplace support environments except development, since they cannot be modified. You can install updates, test them in the stage environment, then publish them to the production application.
   

5. Related Links

1. Managing applications in the environments
   
2. Understanding environments
   
3. Adding applications to environments
   
4. Remove applications from environments
   
5. Application statuses in environments