Hot answers tagged

6

On our product roadmap, we have plans to support installing and upgrading multiple packages in a single transaction. Until that is available, would this multi-step process work for you? 1) Release Package A ver 1.1.0 that has both the methods - global static void doFoo() and global static void doFoo(String msg). 2) Release Package B ver 1.1.0 where doBar(...


5

Generally, is it possible to install two unlocked packages that share overlapping Metadata, e.g. the same custom object? One would need to be a dependent of the other if the exact same metadata exists. Note, however, that a custom object has many related components, which of which may be unique. For example, you might have a custom object, and a dependent ...


4

You should be able to do this through a metadata deployment. If you have a test environment, you can try this out to see if it works. In API version 44.0 and later, you can do this all through the Flow metadata type (no need for FlowDefinition). https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_visual_workflow.htm You'll want to ...


3

There is no neat way of doing this, but you can go old-school. Upgrade all the packages in a sandbox, choosing to only compile the package when you install (which lets you make breaking changes sequentially). Then, use a conventional deployment of the key cross-over classes Foo and Bar (or just all changes) to production. Since they're unlocked, you can ...


3

If installation requires the ContactsToMultipleAccounts feature to be active then the destination org will have to enable prior to being able to install the package. All standard dependencies work like this. If the org does not have or will not enable then they cannot install the package. As for the version numbers and unlocked packages, they are a ...


3

I'm not sure with the answer, but you can test it yourself. First run this command in terminal: sfdx force:limits:api:display Note the current Package2VersionCreates Remaining integer. Then try to create unlocked package with failed status and run the command again. UPDATE: It also would be kind of you if you post your result here in comments to show ...


2

I don't recommend moving EVERYTHING into unlocked packages. Create unlocked packages for individual projects that can stand alone, be tested in a scratch org, and are related to a development team. There is always going to be a sea of unpackaged metadata, many of those standard objects are related to Salesforce CRM functionality. Here is a detailed white ...


2

We have a Dev Hub set up in our company org. Each managed package namespace is set up in that org using Namespace Registries / Link Namespace (see Link a Namespace to a Dev Hub Org). So you just need one Dev Hub for multiple managed packages.


2

Packaging 1.0 (aka Classic Packages) does not particularly support nested packages. However, you could always use DX to retrieve both packages, then create a third package that contains the contents of both. It's also possible create unlocked packages that would behave in a similar manner, except that dependencies have to be installed anyways, so you'd ...


2

There is an extention in VS Code that allows you to choose components and generate package.xml file using point and click Salesforce Package.xml generator for VS Code https://marketplace.visualstudio.com/items?itemName=VignaeshRamA.sfdx-package-xml-generator Affiliation : I am the developer of this free to use VS Code extension


2

Missing feature error while installing package occurs due to two following causes: Org does not support the feature like for instance Professional edition. Package has a dependency of complaining feature. If you are not on PE org, try Enabling communities on the destination org before installing the package.


2

I'd revisit the idea that you should only ever have one trigger per sObject - Apex Trigger Tip: Using One Trigger Per Object To Control Logic. Generally speaking - this is very good advice. But why? We do it to maintain control over the order of execution. If you just piled new triggers into the org every time you needed something new and Salesforce is ...


1

You can make your existing trigger call a packaged class method , so both of the behaviours are processed in the same trigger. Create a new class TrgAccount in your new package (namespace MyNs). global class TrgAccount { global static Account execute(Account account) { // Add more arguments if necessary // Do whatever you need here ...


1

It does appear this error was the result of something done on the Salesforce API side. Trying again 3 hours ago, the command did execute successfully (though it took a bit longer). Should I get any details from the support case, I'll update this.


1

You can't. You will need to create a second Developer Edition org to act as your packaging org. A single Developer Edition is not permitted to be both Dev Hub and packaging org.


1

It does indeed make sense if you can easily split the logic of the applications. But the question is why would you do it? That will require extra maintenance as the new requirements are coming in and you may end up with duplicate code which is a bad practice itself. You will also probably end up doing the same check(which application is running now and which ...


1

The user needs to have the Download AppExchange Packages permission in their profile. If they have the permission, the query on the tooling API returns records from InstalledSubscriberPackage. SELECT SubscriberPackage.Name, SubscriberPackage.NamespacePrefix, SubscriberPackageVersionId FROM InstalledSubscriberPackage If the user does not have the ...


1

the solution I propose uses the Salesforce CLI (find it here: https://developer.salesforce.com/tools/sfdxcli). The reason for this is, that the cli enables you to interact with the org from your local pc. Which includes the most important points here, meaning the retrieval and deployment of your desired metadata. There are five basic steps that you have to ...


1

There is an issue discussed here - https://github.com/forcedotcom/salesforcedx-vscode/issues/680 Retrieving any metadata with a folder structure seems to have this problem. Remove them from package.xml and things should work fine. Use ANT to retrieve the hierarchical metadata and add it to the project folder.


1

I had registered case at Salesforce. So the answer is that it would give an error if the end user don't have Einstein Licenses. What Salesforce recommends is that develop it on extension packages when packaging Einstein Analytics templates. Different Components have different pricing. We need to build Einstein Apps as an Extension package to their base app ...


1

The field needs to exist in the package (or a parent package). This means you'd have a file in objects/Contact/fields/Type__c.field-meta.xml that represents the field in question. A package must be a complete replica of the data, including any dependencies.


1

There are two things you have to do: enable Translations in your Scratch-Org-Def (I guess, you already did). let package-version-create use this scratch org def (I guess, that you didn't) So you scratch org def should looklike this: { "edition": "Enterprise", "language": "en_US", "features": [], "settings": { "languageSettings": { "...


1

The package versions exist in your DevHub, any other changes to your files should be in your repo. The intent of DX is that your repo should be the "source of truth." This means that anything you care about should be in your repo. When creating a new scratch org, you should, in practice, be able to simply use force:source:push to deploy to a scratch org.


1

Currently looking at doing something similar myself - you actually don't need the object.xml in both packages - you can define just the custom fields. You might have found it hard to deploy becuase sfdx push does not currently correctly merge the object.xml from multiple second-generation packages. Can see this demonstrated here: https://github.com/...


1

When I got this error it was because I had some of the same metadata in a seperate unrelated package already installed in the org.


1

Found out it was due to some testSuites I added to group my tests. After removing them from source (folder: testSuites) and re-compiling a new package version, it worked.


1

This might help: 1. sfdx plugins:install sfdx-dependency-plugin 2. sfdx dependency:order -p 04t.. --maxversion --withrootpackage You'll get a list of packages versions ids in the right installation order. Then, using while read ; do...; done you can automatically install package with all its dependencies


1

Tangentially related topic: This can get pretty annoying if you have to deal with package creation in Trailhead modules and try to redo steps to create the specifically named packages. In that case you can at least rename old ones to clear the way with: sfdx force:package:update -n <newname> -d <newdescription> -p <package-(alias or id)>


Only top voted, non community-wiki answers of a minimum length are eligible