Ocassionally due to release windows or on packages that have excessive dependencies, the build time will for an unlocked package will be excessive, this section deals on the possible solutions available

Possible Solutions

1. Wait for Salesforce Updates: The issue should improve once the system is updated to next release for your DevHub

2. Utilize Scratch Org Snapshots: This is particularly useful for packages with many managed dependencies. However, it's worth noting that there are still some bugs affecting package creation in the Closed Beta of this feature.

3. Switch to Source Packages Temporarily: This can be done by renaming the package aliases in sfdx-project.json. However, dependencies to other source packages need to be removed for each source package, as source packages cannot be listed as dependencies for other source packages.

{
  "packageAliases": {
    "myPackage": "04t..."
  }
}

This document provides information on the issues that may arise during the deployment of email templates, particularly in the context of Salesforce Classic and Lightning.

Packaging Lightning Email Templates

One of the known issues is that Lightning email templates cannot be packaged. This issue has been documented in the Salesforce CLI GitHub repository. For more information, refer to the following link: Salesforce CLI GitHub Issue.

Identifying the Type of Email Template

When working with email templates, it's important to identify the type of email template not from the file type, but from the type tag. This is because both types of templates are referred to as 'email', while one is of type 'SFX' and the other is of type 'Aloha'.

Distinguishing Folders

Folders can be more reliably distinguished. They use 'EmailFolder' for Classic and 'EmailTemplateFolder' for Lightning as their opening tags. This distinction is important to note before deploying the templates.

Please ensure to take these precautions prior to deployment to avoid any issues.

1. Alias Name Matching

• Issue: Deployment fails due to mismatch in the alias names.

• Solution: Ensure the alias name used in Salesforce CLI matches the intended org's alias exactly, including case sensitivity. Alias names are case sensitive, so MyAlias and myalias would be considered different.

2. Adding Parent Folder Name to Release YML File

• Issue: Confusion about defining directories or packages in the release definition file.

• Solution: In the release definition (*.yml) file, specify packages rather than directories. In some cases, the "path" and "package" may coincide, such as src-env-specific-alias-pre.

3. Building and Adding Packages to Artifact Directory

• Issue: "Aliasified" packages are skipped during the build process.

• Solution: Even though the template might skip "aliasified" packages, it's recommended to include them in the build process for the latest setup. Ensure these packages are built and added to the artifact directory.

4. Setting AlwaysDeploy Flag

• Issue: Packages not deploying as expected.

• Solution: Check if the alwaysDeploy flag is set in your configuration. This flag ensures that certain packages are always deployed, regardless of other conditions.

5. Using Multiple Force Ignore Feature

• Issue: Need to exclude specific files or directories from deployment selectively.

• Solution: Utilize the multiple force ignore feature to manage what gets included or excluded in your deployment package more granely.

6. Updating Force Ignore Files

• Issue: Alias packages are unintentionally included in builds or deployments.

• Solution: Create an additional .forceignore file to exclude alias packages specifically for build and quick build processes. Note that regular force ignore files are not applied during release, allowing everything to deploy as expected.

When encountering an issue where the build command builds an artifact that is incompatible with the target Salesforce environment, it's important to understand the role of the sourceApiVersion in the sfdx-project.json file and other factors that might influence the API version used during the build.

Understanding the sourceApiVersion

The sourceApiVersion in your sfdx-project.json file is intended to specify the default API version for your Salesforce DX project. This version is used when creating scratch orgs and can influence the API version used for package builds. However, if your build results in a package versioned at 59.0 while your sourceApiVersion is set to v55.0, this need to be resolved

Resolving the Version Mismatch

To resolve the version mismatch and ensure your package is built with a compatible API version for your sandbox, consider the following steps:

• Review and Align Configuration Files: Double-check your sfdx-project.json and any other configuration files involved in the build process. Make sure the sourceApiVersion is consistently set to the intended version across all configurations.

• Check CLI and Plugin Versions: Ensure sfp cli is up-to-date. Review the documentation or release notes for these tools to understand their behavior regarding API version selection.

• Specify API Version in Build Command: If possible, use command-line options to explicitly specify the API version when issuing the build command. For example, some CLI commands allow you to set the API version directly as an argument.

By understanding the factors that influence the API version used during the package build process and taking proactive steps to align your project's configuration with your target environment, you can avoid version compatibility issues and ensure smooth deployments.

Overview

The alwaysDeploy attribute for packages is designed to always deploy a package, regardless of other conditions. However, it only runs if the package is available in the collection of artifacts to be deployed. It then deploys the package, regardless of whether the package was previously installed or not.

On the other hand, the skipIfAlreadyInstalled attribute allows the deployment process to skip the installation of a package if it is already installed.

Interaction between alwaysDeploy and skipIfAlreadyInstalled

The alwaysDeploy attribute should work when skipIfAlreadyInstalled is set to true. However, it's important to note that alwaysDeploy only deploys a package if it was built in the previous step. Therefore, if your requirement is to always deploy a package, regardless of whether it was changed or not, alwaysDeploy will not solve your requirement.

The Install Command

The install command is based on the existing artifact files in the artifacts directory. The --artifacts --release-config parameter filters artifacts available for usage. The same applies for alwaysDeploy; if the artifact is not available in the provided directory, it won't install because there is no such artifact available. In contrast, the release command first fetches the artifacts (based on the config file) then installs them.

In summary, the flag "alwaysDeploy" could be better described as: If the artifact is available, then deploy it.

Workaround for Always Deploying a Package while using install command

If you need to always deploy a package ensure you fetch the artifact into the artifact directory, so sfp's command will pick up the artifact as part of the collection

When integrating record types and standard value sets in Salesforce, particularly in the context of unlocked packages, teams may encounter issues with picklist values not being correctly associated with their respective record types upon installation. This article provides a solution to ensure a smooth deployment process that maintains the integrity of picklist assignments within record types.

Problem Statement: In situations where standard value sets are stored in an unpackaged directory and associated with record types in an unlocked package, the expected picklist values may not be properly applied upon installation. This results in all possible picklist options being displayed, contrary to the intended configuration.

Observations:

• This issue does not affect all record types within a package, as some may correctly reflect the selected picklist values.

• Manually setting standard picklist fields and referencing them in the record type does not prevent the issue; upon installation, all values become visible if not explicitly defined.

• Removing the reference from the record type within the package causes Salesforce to default to displaying all picklist values.

Solution: The sequence of deployment plays a crucial role in addressing this challenge. It is essential to deploy standard value sets prior to installing the unlocked package. To facilitate this, a preliminary package (referred to as env-specific-pre) containing the necessary components can be created. This package should include the standard value sets, ensuring they are in place before the main unlocked package is introduced to the org.

Implementation Steps:

1. Create a preliminary package named env-specific-pre or a similar identifiable name.

2. Include the standard value sets in this package, ideally in a dedicated directory (e.g., src-env-specific-pre/standardValueSets).

3. Ensure that this package is deployed to the Salesforce org before the installation of the main unlocked package.

4. Modify the seedMetadata configuration in the unlocked packages to reference the path of the standard value sets, as shown below: