What we think we can do is to create User custom field (encrypted session ID) and populate it every time user logs in. Then we could use it in the url. (We haven't tried yet though since we still hope that there's a more elegant solution for this problem.)
Could someone please advise on how FLS on standard objets custom fields is applied when installing a managed package? I am a bit disappointed by the difference between what I'm seeing in documentation and what I'm getting as the result.
We have external id text fields for accounts and contacts which we then use for integration with our systems, let's say: Account.Custom_ID__c and Contact.Custom_ID__c. We are installing this package to both new SF environments and SF environments that may already have the same custom fields for contacts and accounts. Though 'installed' custom fields have namespace prefix and thus their names are different from the ones that had previously existed in these SF orgs, it seems that their visibility depends on it. I have tried different combinations of SF orgs and step 2 security levels for installation and here are my conclusions:
Grant access to admins only. Expected: all custom fields from the package are visible for System Administrator profile. In reality: custom fields are not visible to any profile (if these fileds already exist in this SF org) OR some chaotic set of profiles (not only administrator and not only custom profiles) has visibility checked for this field (otherwise).
Grant access to all users. Expected: all custom fields from the package are visible for all custom profiles. In reality: the same as for previous option.
Select security settings. Here I should be able - in theory - copy some of profile settings from the custom profiles that I included into package. In reality: if these fileds already exist in this SF org then they (the new ones) are not visible to any profile, otherwise they are visible to all profiles. Regardless of the mapping I've chosen.
What we think we can do is to create User custom field (encrypted session ID) and populate it every time user logs in. Then we could use it in the url. (We haven't tried yet though since we still hope that there's a more elegant solution for this problem.)
Could someone please advise on how FLS on standard objets custom fields is applied when installing a managed package? I am a bit disappointed by the difference between what I'm seeing in documentation and what I'm getting as the result.
We have external id text fields for accounts and contacts which we then use for integration with our systems, let's say: Account.Custom_ID__c and Contact.Custom_ID__c. We are installing this package to both new SF environments and SF environments that may already have the same custom fields for contacts and accounts. Though 'installed' custom fields have namespace prefix and thus their names are different from the ones that had previously existed in these SF orgs, it seems that their visibility depends on it. I have tried different combinations of SF orgs and step 2 security levels for installation and here are my conclusions:
Grant access to admins only. Expected: all custom fields from the package are visible for System Administrator profile. In reality: custom fields are not visible to any profile (if these fileds already exist in this SF org) OR some chaotic set of profiles (not only administrator and not only custom profiles) has visibility checked for this field (otherwise).
Grant access to all users. Expected: all custom fields from the package are visible for all custom profiles. In reality: the same as for previous option.
Select security settings. Here I should be able - in theory - copy some of profile settings from the custom profiles that I included into package. In reality: if these fileds already exist in this SF org then they (the new ones) are not visible to any profile, otherwise they are visible to all profiles. Regardless of the mapping I've chosen.
