Develop Analytics Templates in 1GP and 2GP packages

Question

I want to build a Managed Packaged with TCRM / CRM Analytics / Einstein Analytics elements in a distributed fashion using SFDX, Version Control and Scratch Orgs.

I understood from the documentation that I do need a long-lived Developer Org with Analytics Studio to create and evolve the Master App from which I create a Templated App that will become part of my Managed Package.

But I am very confused by all the requirements around orgs that come with 1GP vs. 2GP and Namespaces in Analytics:

1. Should I go with 1GP or 2GP? Why?
2. If I decide to go with 1GP, should I create the Master App in the Packaging Org or a separate Dev Org?
3. If I go with 1GP and a separate Dev Org for TCRM, who do I keep the same Namespace as proposed in https://help.salesforce.com/s/articleView?language=en_US&id=sf.bi_packaging_considerations.htm&type=5
4. If I go with 2GP, must I create the Master App and Template in a Namespaced Scratch Org?
5. How do keep the Master App Id / Folder Id persistent when I just use Scratch Orgs?

Answer 1

Should I go with 1GP or 2GP?

2GP.

Why?

Because 2GP is better than 1GP for virtually anything you want to do. You can associate package versions to branches in your repo. You can undo a bad version by branching off an earlier version. The package is built on your own source code in the repo instead of residing a Packaging Org, where an accidental modification or deletion can break the package (in 1GP). The only reason why you'd want a 1GP is if the package requires 1GP-only features (see the Metadata Coverage Report).

If I decide to go with 1GP, should I create the Master App in the Packaging Org or a separate Dev Org?

You'll use the existing Master App that you already have as the source to get started. This should be in your Packaging Org. You'll just pull down the WaveTemplateBundle, create a Scratch Org, push to the org, and you're ready to go.

If I go with 1GP and a separate Dev Org for TCRM, who do I keep the same Namespace as proposed in https://help.salesforce.com/s/articleView?language=en_US&id=sf.bi_packaging_considerations.htm&type=5

Namespaces cannot be shared across Developer Edition orgs. You link a namespace to your Dev Hub Org, then you can create Scratch Orgs with that namespace.

If I go with 2GP, must I create the Master App and Template in a Namespaced Scratch Org?

The "Master App" will be created in each org. This video goes over the details (it doesn't use a namespace, but the steps should be identical).

Before you begin, you need some setup first. I'm going to assume that you've done nothing yet, so skip any steps you need to.

1. Install VS Code, sfdx-cli, and the Salesforce DX plugin @salesforce/analytics
2. Enable Dev Hub in a non-namespace Developer Edition or a production org
3. Create a Developer Edition and set a namespace; this will be different than the Dev Hub org
4. Link your namespace to the Dev Hub
5. Authenticate with sfdx force:auth:web:login or another means for both devhub and Developer Edition org
6. Create repo or clone from an existing repo
7. Create a local project with sfdx force:project:create
8. Update sfdx-project.json and your Scratch Org Definition File (in the config/ folder) to use the namespace
9. Commit everything

Once you've set everything up, now you can get to work with the template. Retrieve the WaveTemplateBundle from the packaging org or whatever source org you have right now. You can do this by specifying package name -n "Package Name", metadata type -m WaveTemplateBundle, package manifest -x package.xml, etc. You only need to do this once, as the Packaging Org/original source is no longer the "source of truth." That role now belongs to your repo.

Next, you will create your 2GP with force:package:create.

For development, you will generally go through the following steps:

1. Create a new Git branch
2. Create Scratch Org (force:org:create)
3. Push the template to the Scratch Org (force:source:push)
4. Create a new App (analytics:app:create)
5. Update the template to use the new folder Id (analytics:template:update)
6. Update the app to use the template (analytics:app:update)
7. Do any work necessary in the JSON and push, or do any work in the app, update the template, and pull
8. Commit changes
9. Create new 2GP version
10. Promote, if necessary
11. Delete the Scratch Org when you're done with it
12. Do any merges/pull requests

How do keep the Master App Id / Folder Id persistent when I just use Scratch Orgs?

You create a new app every time. It's not the app that's updating, it's the template. Like I mentioned earlier, the video goes over the entire process from start to finish, which is also outlined in the list above. Each org will have its own app. I haven't personally tested every step, but this looks fairly complete.

Answer 2

These are the mistakes I have made until I learned the hard way. Hope this helps.

Use the right tools

• Salesforce Analytics Extension Pack
• Salesforce Analytics CLI Plugin

Use Git right

Use .forceignore to pull only the template file in the package force-app/main/default/wave/ force-app/main/default/waveRecipe/*

How to debug

• Check the App Install History page in your org (Setup > Feature Settings > Analytics > Apps > App Install History). It contains detailed information about each step involved in app creation from a template.
• For more detailed logging, set the Log Level to Finest when creating the app through Studio.
• If the App Install History page does not contain enough information, check the App Log. AppLog is a json field located in InsightsApplication BPO.
• You can also find it by adding the “filterGroup=Supplemental” parameter to the /wave/folders url in workbench on the REST explorer (/services/data/v52.0/wave/folders/?filterGroup=Supplemental). The "appLog" object will populate and you can take a look at the Items stored there to see the individual entries in the app log.

Updates/upgrades

1. Put the template in source control
2. for development, use the template to create an app
3. update the template from the created app.
4. When ready to iterate, push the template into scratch org,
5. build your master app from the template.

The source of truth should be your template and on the file system.

Answer 3

I also shared this question in the Partner Community and received two great insights:

Skip Sauls (Salesforce): You don't need a long-lived developer org. The template is the source of truth. Spin up a scratch org, load the template, create the master app, make changes to the master app, update the template, export the template, and check into Git.

Daniel Elkington (Socialsuite): That part took me a while to get my head around, too - the idea that the template can be updated with changes that are made to an app instance generated from the template. Template Ids and Folder Ids are only relevant to the sfdx commands you're running, they dont need to be persistent from a packaging perspective. Using scratch orgs doesnt require 2GP, we have a 1GP with a templated app that we've built & maintained using scratch orgs.