Feed

@Ajaypal Ajaypal this is a limitation of standard Salesforce reporting on LoginHistory.

LoginHistory is queryable, but it is not a good source for standard Salesforce Reports/Dashboards because it is not available like a normal reportable object/custom report type. Also, fields like Application and Platform

are not filterable in SOQL, so you usually need to query by date first and then group/filter the results outside the query. 

Reference:

For Salesforce mobile app adoption, the practical options are:

Use Setup → Login History

and export the data. Salesforce also has a help article specifically for tracking Salesforce for Android/iOS logins from Login History: 

Or use SOQL/API and pull recent login records, then process the result in Excel, Tableau, CRM Analytics, or a custom object:

SELECT Id, UserId, LoginTime, Application, Platform, LoginType, Status, SourceIp
FROM LoginHistory
WHERE LoginTime = LAST_N_DAYS:30
ORDER BY LoginTime DESC

Then filter/group the exported result for mobile values like Salesforce for iOS / Salesforce for Android.

For Salesforce-native dashboards, create a small custom object such as Mobile Login Snapshot, load summarized LoginHistory data into it daily, and report from that custom object.

If you have Shield Event Monitoring, that is the better long-term route. Event Monitoring Analytics gives deeper usage/adoption insights from event data: 

The standard Lightning Usage App

is also useful for general Lightning adoption, but it will not fully replace mobile-specific LoginHistory/Event Monitoring analysis: 

@Murali Pathivada This is a standard polymorphic relationship behavior on ContactPointAddress.ParentId, not something to design around as if it will always stay Account-only. Salesforce’s object reference lists ParentId as a polymorphic relationship that can refer to Account or Individual: https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_contactpointaddress.htm

For long-term maintainability, the cleaner option is Option 1: add a dedicated custom lookup to Account.

Keep ParentId as the standard Salesforce parent relationship, but add something like Account__c on ContactPointAddress and populate it from ParentId when the parent is an Account. Then update validation rules, flows, reports, and formulas to use Account__r instead of trying to traverse the polymorphic Parent.

That gives you a stable relationship path for business logic. Salesforce supports cross-object validation/formula logic through normal lookup or master-detail relationships, which is exactly what the custom Account lookup gives you: 

Option 2 works technically, but it pushes too much logic into flows. Every validation that needs Account data would need a Get Records step, and validation rules that previously referenced Account fields would need to be rebuilt using Flow custom errors. Flow custom errors are useful, but they are heavier to maintain than a clear relationship field: 

You should:

Create Account__c lookup on ContactPointAddress 

Backfill it from existing records where ParentId points to an Account 

Use a before-save flow or Apex trigger to keep it in sync 

Add validation to require Account__c if your business says every delivery address must belong to an Account 

Move formulas and validation rules to Account__r 

Only use polymorphic ParentId where Salesforce requires it

For querying polymorphic relationships, SOQL supports polymorphic handling, but that does not solve the validation rule/formula maintainability problem: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_SOQL_polymorphic_relationships.htm

Hi Kimberly - I think I'm following your use case.  The way Salesforce is architected around campaigns means that in order to have a Campaign Member you'll need to either have a corresponding Lead or Contact record; a Campaign Member record cannot be created without one of those. (In essence you'll have 2 records - one Campaign Member and the other a Lead or Contact.) 

Given the scenario you mentioned above, you can put the basic information either on the Lead/Contact record or the Campaign Member - I would just think carefully about if/how the information will be used in the future or for reporting.  Typically I would recommend that person-specific information be on the Lead/Contact record and then event-specific information be on the Campaign Member record.  Finally, given the desire to not create new leads (but necessary because of Salesforce architecture), I would recommend creating a Lead Status picklist value that is not in your current process that the invitees' guests can be set to so they are not contacted by your sales/marketing team.  (You could also do a custom field on the Lead/Contact record, but a picklist value would be better overall depending on how your sales process is constructed.) 

Feel free to reach out if you would like to talk through the scenario further. 

@Selvasubha R there is no single Salesforce document for “MCAE API query -> generate file -> push to SFTP” because the SFTP/file-generation part is a custom middleware responsibility.

For click details, use the Account Engagement API, usually Visitor Activity. Click activities are available there, including activity type 1 for Click and 21 for Custom URL Click: 

https://developer.salesforce.com/docs/marketing/pardot/guide/visitor-activity-v5.html

For larger exports, use the Account Engagement Export API instead of normal synchronous queries: https://developer.salesforce.com/docs/marketing/pardot/guide/export-v5.html

The usual architecture is: MCAE API -> middleware job -> transform response to CSV -> upload CSV to SFTP. The middleware can be MuleSoft, Boomi, Workato, Azure Function, AWS Lambda, Python/Node scheduler, etc. Salesforce will provide the API endpoints and authentication, but the SFTP upload, file naming, scheduling, retry logic, and logging need to be built in the middleware.

If this is Marketing Cloud Engagement SFTP, Salesforce documents SFTP usage here: https://help.salesforce.com/s/articleView?id=mktg.mc_overview_ftp_accounts.htm&type=5

For Account Engagement specifically, treat the API as the data source and the SFTP delivery as a custom integration layer.

@Erin Duncan Salesforce now blocks outbound email from unverified sender domains. That is why the email send fails even though the prompt template may be configured correctly. Check: https://help.salesforce.com/s/articleView?id=005316090&type=1

In the superbadge org, try enabling the substitute sender option for users whose domains can’t be verified Setup -> Email -> Send Email for Users with Unverified Domains 

Check: https://help.salesforce.com/s/articleView?id=xcloud.security_user_email_verification_substitute_domain.htm&type=5

After that, go back to Robinette Bullman’s Contact record and send the email again using Draft with Einstein -> Program Recommendation Email

. The superbadge page confirms the email must actually be sent using that prompt template: 

Also check Setup -> Deliverability and make sure access is set to All Email.

If the substitute sender option is not available in the special DE org, open a Trailhead Help case. The challenge requires an actual email send, so this cannot be bypassed just by previewing the prompt.

@Pankaj Malik For this challenge, the Share Applicants Between Recruiters rule should have access set to Read Only.

In the UI, Salesforce may show it as Read Only, while the challenge message may say Read.They mean the same thing here.

Please edit the sharing rule and confirm these values:

Object: Applicant 

Rule Label: Share Applicants Between Recruiters 

Rule Type: Based on record owner 

Owned by: Roles: Recruiter 

Share with: Roles: Recruiter 

Access Level: Read Only

Then save, wait a minute for sharing recalculation, refresh Trailhead, and check the challenge again.

Trailhead reference: https://trailhead.salesforce.com/content/learn/projects/protect-your-data-in-salesforce/create-opportunity-sharing-rules

@Duru Zerdali screenshot shows you are already in the right place:

App Manager -> Ursa Major Solar Service Console -> Utility Items -> Add Utility Item

If Omni-Channel is not appearing in that list, it usually means Omni-Channel has not been enabled yet in the org.

Go to: Setup -> Omni-Channel Settings -> Enable Omni-Channel -> Save

Then refresh the App Manager page and come back to: Ursa Major Solar Service Console -> Utility Items -> Add Utility Item

Now search for Omni-Channel again and add it.

Salesforce’s help confirms that Omni-Channel must be enabled first: 

https://help.salesforce.com/s/articleView?id=service.omnichannel_enable.htm&type=5

Trailhead’s step then asks you to add Omni-Channel from the app’s Utility Items section: 

https://trailhead.salesforce.com/content/learn/projects/set-up-the-service-console/set-up-web-chats-for-your-console

Also make sure you are editing the Ursa Major Solar Service Console Lightning app, not a standard app. Your screenshot shows the correct app, so the missing piece is most likely the Omni-Channel enablement step.

@Angela Mullen-Smith, don’t install DevOps Center from an old AppExchange/package link. That is usually where the “package out of date” issue comes from.

Install it from inside Salesforce instead:

Go to Setup -> Quick Find -> DevOps Center

Enable DevOps Center

Accept the terms 

Click Install Package from that same DevOps Center setup page 

Install for Admins Only 

After installation, assign the DevOps Center permission sets to yourself/admin users

Salesforce’s official setup doc says to install the managed package from the DevOps Center Setup page, not from a stale AppExchange link: https://help.salesforce.com/s/articleView?id=platform.devops_center_setup_install.htm&type=5

The Trailhead quick look also says to start from Setup -> DevOps Center: https://trailhead.salesforce.com/content/learn/modules/devops-center-quick-look/say-hello-to-devops-center

For a proper implementation, install DevOps Center in your main release/governance org, usually Production. You can still use sandboxes as development, SIT, UAT, and release environments in the pipeline. 

If you only want to test it first, use a Developer Edition org rather than trying to install it into a sandbox with an old package link: https://help.salesforce.com/s/articleView?id=platform.devops_center_setup_install_de_org.htm&type=5

Helpful video/tutorial: https://www.salesforceben.com/salesforce-devops-center-step-by-step-tutorial/