The tooling API from Salesforce can now let you determine if a profile is custom or not.
Calling the following for example:
It gives you a json response with "Metadata" property that contains a "custom" property set to true or false.
You will have to call that API for each profile to get ...
in order to get every information about the profile, you have to create a package.xml file where you have to mention all the metadata for which you want to see the profile permissions. The below package.xml file contains custom objects, applications, tabs and profile. The profile metadata file will have information about user permissions, custom object field ...
What does "Read/Write" access on Sharing Rule really signify if an Object has only "Read" access on the Profile and that the record can actually never be edited?
You'll want to read Sharing Considerations for most of the usual complications of sharing.
However, for the purpose of this question, it's important to make a distinction. A feature that requires ...
The reason this isn't working for you is this condition:
As this logic is in (or called by) an Account Trigger, only the values on the triggered object (i.e. Account) are implicitly available in any of the Trigger context variables (like Trigger.New)
You will need to query for the parent values for all Accounts in the ...
Now that I see this, an alternative answer is to use Workbench and do a describe on the profile sobject (albeit, less convenient than seeing it all laid out per the Salesforce Inspector)
I found them using the Salesforce Inspector Chrome Add-on on a profile in my org. I click on show all data (tooling api) and see the below which matches up well with what you already got:
permissionsenablenotifications - Send Outbound Messages.
permissionsemailtemplatemanagement - Manage Email Templates
permissionsemailadministration - Email Administration