We can't display this page because your browser blocks cross-domain cookies, but you can view this page in Salesforce Classic. Click here to open this page in Salesforce Classic.

Salesforce Lightning Admin browser blocks cross-domain cookies use Classic

I see lots of other folks running into this and thought I would post the fix along with my thoughts. (TL;DR).

The error message is “We can’t display this page because your browser blocks cross-domain cookies, but you can view this page in Salesforce Classic. Click here to open this page in Salesforce Classic.” It can happen in several screens and is a result of some of the base domain changes that Salesforce has been making coupled with the security changes browsers have been making. For chromium-based browsers (Edge, Chrome, Brave, etc.) the fix is to add your domain to the cookie exception list.

With screens, the process go as follows:

Go to Settings > Privacy and security
Go to Settings > Privacy and security
Select Cookies and other site data
Select Cookies and other site data
Under Sites that can always use cookies click the Add button
Under Sites that can always use cookies click the Add button
Paste your SFDC domain path in the Site dialog and Check Including third-party cookies on this site
Paste your SFDC domain path in the Site dialog and Check Including third-party cookies on this site

Click the Add button and

Refresh your Salesforce screen [F5]
Refresh your Salesforce screen [F5]
Tada!

Note: You could use a wildcard in place of the sub-domain for all salesforce domains, but I don’t recommend that as it would leave you vulnerable to some miscreants that use their orgs for nefarious purposes.

To summarize:

  1. Go to Settings > Privacy and security
  2. Select Cookies and other site data
  3. Under Sites that can always use cookies click the Add button
  4. Paste your sub-domain and domain path in the Site dialog
  5. Check Including third-party cookies on this site
  6. Click Add button
  7. Refresh your Salesforce screen [F5]
If you found this interesting, please share.

© Scott S. Nelson
In what city were you born?

SOLVED! Salesforce “In what city were you born?” not set.

TL;DR – The default answer to security question “In what city were you born?” is San Francisco

Here’s the scenario: You signed up for a new free Salesforce Developer account. After filling the form properly you get the screen that they have sent a verification email and, lo and behold, it is immediately in your inbox. You click the link and get…a DNS error. Well, that is annoying, but understandable given the volume of traffic Salesforce deals with. It will propagate eventually, so you decide to come back later.

Later, you come back and the DNS now resolves to your shiny new org, but now the new user token has expired and instead of the prompt to change your password you just get the regular old login screen asking for a username that is in the email and a password that has never been created. This is a Charlie Brown and Lucy place-kicking moment.

Well, this has happened to me a few times, and in the past I just created a new account and eventually would get a notification that the previous org was being decommissioned for non-use. But today I didn’t feel like filling the form out again, so I tried something unique (for me)…when prompted for city on the password reset screen I first tried blank, since that is what it would be if it was never set. That resulted in a note that I was wrong (not the ISO-270001 recommendation, BTW). So I thought “what would have I set as a default response?” And then I thought “the city where headquarters is”. And I was right.

Cheers!

If you found this interesting, please share.

© Scott S. Nelson
Daily Limit Reached

Solution for sfdx package create error “couldn’t retrieve the design time component information for component”

(Formerly titled SOLVED! sfdx force:package:version:create -p error: We couldn’t retrieve the design time component information for component)

Now and then I find myself looking for what I expect to be a simple set of steps for what seems to be a common need and instead wind up on a Google journey that is frustrating as all heck. I hit a double-header in this area over the weekend (ironically, following the steps from my own post Get Hands-on with VS Code, Salesforce DX and Packages), and while the second annoyance is still annoying me the first part was resolved and I’m sharing that here. While I won’t make you repeat all the steps I went through to complete a 5 minute task in as many hours, I will share the path before the conclusion (tldr;).

Problem: running force:package:version:create -p to create an unlocked package for an app that has a dependency on a managed package results in an error “We couldn’t retrieve the design time component information for component [foo:bar]”.

Ok, simple enough. Add the managed package as a dependency. GiMF, so off I go and find https://salesforce.stackexchange.com/questions/236881/how-do-you-create-a-package-version-with-dependencies-on-both-2gp-and-1st-gen-ma which usefully points out I need to add the package as dependancy and some examples of what it looks like. Hmmm. I note a key requirement is the package ID. There examples clearly show the ID but no where in the thread does it mention how to get the ID. Down the search engine rabbit hole again to find https://developer.salesforce.com/docs/atlas.en-us.222.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_config_file.htm, which tells me exactly how to find it for my own packages, but not a hint of how to do this for a package from AppExchange. Continuing on… I find how to find the info using SOQL at https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_extract_dependency_info.htm, but, alas, still only good for my own packages.

Eventually I found this command (and, in all honesty, I was so frustrated by then that I lost the link where I found it):

sfdx force:package:installed:list -u [alias to org that has managed packaged installed]

Which rendered:

ID Package ID Package Name Namespace Package Version ID Version Name Version
------------------ ------------------ -------------------------- ------------ ------------------ ----------------- --------
0A375000000GsstCAC 0332E000000U76DQAS Launch Flow Modal sf_flowmodal 04t2E000003VsuMQAS Launch Flow Modal 1.14.0.1
0A375000000Gss2CAC 03330000000wDAbAAM Salesforce Connected Apps sf_com_apps 04t30000001DUvrAAG Winter '16 1.7.0.1
0A375000000GssoCAC 0333X0000006XwlQAE Enhanced Approval Requests ear 04t3X000002xUYTQA2 Summer 2021 1.10.0.1

And yay, I had what I needed to create the entry depencies entry for managed packages used by an unlocked package:

"dependencies": [
    {
        "subscriberPackageVersionId": "04t2E000003VsuMQAS"
    },
    {
        "subscriberPackageVersionId": "04t3X000002xUYTQA2"
    }
]

Basically. I actually would have preferred to find the 0Ho ID so I could also just use LATEST instead of the last digit of the version, but alas, time to move on to the remaining issue(s):

Picklist value: ...not found
Defined value not found

Which I am stopping on today because:

ERROR running force:package:version:create: The package2 version create request failed because this organization has reached its daily limit
Author has (also) reached its daily limit

In summary, to add a managed package as a dependency for an unlocked package:

With an org where the managed package is installed run the following:

sfdx force:package:installed:list -u [alias to org that has managed packaged installed]

Then add this to your sfdx-project.json under packageDirectories that contains your package:

"dependencies": [ { "subscriberPackageVersionId": "04tPACKAGEID" } ]

Where 04tPACKAGEID is the value returned from the CLI command.

If you found this interesting, please share.

© Scott S. Nelson
sfdx cli versions.map-is-not-a-function

FIXED! ERROR running force:mdapi:retrieve: versions.map is not a function

Ran into this fun error message today when attempting to pull from a Salesforce sandbox from the CLI:

ERROR running force:mdapi:retrieve: versions.map is not a function

Most of what I found on the web was FUD and also about trying to push rather than pull. The comments all seem to agree it was related to the recent update for Enhanced Domains on Winter23-enabled sandboxes.

Fortunately for me, I had just added another org to my CLI. I was surprised at no approval prompt and it got me to thinking that I had probably authorized it before. So it occured to me that the fix may just be to run the authorization again, i.e.,

sfdx force:auth:web:login --setalias [ALIAS] --instanceurl [MY.DOMAIN.URL]

And that did the trick for me. Hope this helps others.

If you found this interesting, please share.

© Scott S. Nelson
Trailhead as an option on LinkedIn in Education