Salesforce is Point & Click

550-5.7.26 Unauthenticated email from [DOMAIN] is not accepted due to the domain's DMARC policy The message is unambiguous, you have an issue with the DMARC policy.   You can find the message in the email log, in those lines with a "P" in the Mail Event column. But ... can we trust the error message? Well ... let's see. DMARC/DKIM/SPF & NSLOOKUP Domain-based Message Authentication, Reporting, and Conformance (DMARC)  is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing ... DMARC extends two existing email authentication mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) . It allows the administrative owner of a domain to publish a policy in their DNS records to specify how to check the From: field presented to end users; how the receiver should deal with failures – and provides a reporting mechanism for ac

A permission set group streamlines permissions assignment and management. Use a permission set group to bundle permission sets together based on user job functions. Users assigned the permission set group receive the combined permissions of all the permission sets in the group. Reference: Salesforce   In these two articles: Salesforce Profiles and  Salesforce Permission Sets  we found that the Minimum Access - Salesforce profile approach proposed as a general solution and in particular for the Data Security Trailhead module can lead us to have so many permission sets that it can be a challenge to manage them. It is normal to reach the same conclusion as this Trailhead module Get Started with Permission Set Groups  when they say: " ... given how quickly permission sets can multiply, you may have wondered how to simplify permission set management .. .". And yes, you are correct 😀, the solution is the Permission Set Groups. And the main reasons to use Permission Set Groups

A permission set is a collection of settings and permissions that give users access to various tools and functions. Permission sets extend users’ functional access without changing their profiles. Reference: Salesforce   We need to remember what a Salesforce Profile is and always keep in mind this: extends users' functional access without changing their profiles . That is key: I need these types of users to do something else, then I might create a new Permission Set for that function (like for instance, including a permission set to force Multi-Factor Authentication or to "make" a user a Knowledge Base Reader). ... then use permission sets to grant more permissions as needed ... In the  Salesforce Profile  article, I proposed a solution based on the Minimum Access - Salesforce profile for the Hiring Application introduced in the Data Security Trailhead Module. These were the Permission Sets proposed: Position - CREx Position - xRxx (No min/max pay)

Profiles define how users access objects and data, and what they can do within the application. When you create users, you assign a profile to each one. Reference: Salesforce   And my recommendation is that, before you start and create a Profile for each Role in the Role Hierarchy , you should read carefully what a Permission Set is, how it defines too how users access objects,  and get a good understanding of what is the difference between a Profile and a Permission Set . Check the table at the end of this post The Fall of the Profile Empire  to see what you can do only with profiles. The Profile Minimum Access - Salesforce  proposed approach I will use the example Hiring Application proposed in the Data Security Trailhead Module to develop the approach. Regarding data security, the module deals with permissions at 4 levels: Org, Object, Field, and Record. But I will work with only two levels: Object and Field. The required permissions are: Custom Object