Lindsay Agor - 1 year ago
@Nicole Dec upvote idea https://success.salesforce.com/ideaView?id=08730000000BrP6AAK as access to a long text fields could be managed through field level security.
@Ying Wang... can long text fields on tasks and events please be reviewed for inclusion in a release?
Nicole Dec - 1 year ago
The problem is as others have mentioned. Companies need to track their Sales Reps activities. A major benefit of Salesforce is to report on Calls, Events and Tasks. However, in the Sales world those tasks are private to that user. There are use cases where a Company may use one Salesforce instance but have multiple divisions where their sales is ultimately a compeition, thus one sales rep should not see the others activities. Why not have it when the OWD is set to private for an Object, then have the Activities controlled by that. So for example the work around would be if I set Accounts to PRIVATE, but need to make the Sharing Rule with a Sharing Group of all internal users so that they can still Read/Write (not to create duplicate Accounts) - but since the Accounts would be PRIVATE - the activities would be Private to all users.
Lindsay Agor - 1 year ago
Could long comment fields be looked at as a solution so we can limit visability to a custom comments field through FLS?
The long comment fields idea is here https://success.salesforce.com/ideaView?id=08730000000BrP6AAK
Peter Bender - 1 year ago
The decision to never implement sharing features for Activities so that they are consistent with other objects and platform security options is very disappointing. However, if Salesforce isn't ever going to do that, we at least need the ability to hide (prevent acess) to all Activities - the object itself. That way if necessary we can build custom solutions with Apex to override the default visibility rules of "if you can see the record you can see the Activity". Such a solution would make it possible to hide all Activiites by default and then only show the records that we consider appropriate, using custom fields and logic to indicate how to share the record via a custom UX using the "without sharing" option if necessary. This is obviously far from ideal, but does provide a (expensive and more difficult) method for addressing important security concerns, unlike the current situation. To that end, there already is a permission "Access Activities", but apparently it is only functional for Community users, since for all other license types the setting is on/true and cannot be edited. This idea would cover it, for instance.
Ying Wang - 1 year ago
Hi all, thank you for your passion for this idea. The team has evaluated the feasibility of addressing this idea since the last update. Trust is our number 1 value and we prioritize scale and performance concerns in all the enhancements we build. Unfortunately, it’s extremely difficult and very costly to change Activity sharing without degrading your experience. Therefore , we don’t plan to address this idea for Activities.
Activities added by Einstein Activity Capture do support “private” sharing, where only recipients/participants of the email/event can view the activity details in timeline (more info is available here) . While I realize there are change management implications to going this route, it may help address some of the use cases listed here.
Tania Gueifao - 1 year ago
Why this issue have 12 years?
I have worked in multiple orgs and this has been a problem every time.
This is a privacy issue for us and like others said before is a big problem regarding the GDPR.
Having access to an account/ contact or opportunity does not should gives read access to related activities..
In my opinion
>>Feature 1) is essential and should work , OWD (really) Private to activity and be able to grant access with role hierarchy
On the other hand ability to use sharing rules with activity object.
>>The feature 2) could be a plus, the new private checkbox could be made visible to some 'profiles'/or permission set (FLS) would granted that only some users and admins could access to the activity.
Stephen Johnson (Primary|Certs) - 1 year ago
This has been affecting our Org since 2012.
To answer both questions:
Bryan Snyder - 1 year ago
The amount of customization that is required as a result of the unique sharing on Activities is incredibly high. I have seen the use of custom objects instead of the the OOB Activities and masive changes to the underlying data models.
Salesforce, can you comment on this? Will there be any change to this in the future?
Tessa Stevens - 1 year ago
I would also like to have an update on this from Salesforce. It would be great if Activities (Tasks & Events) could be set as public or private and shared through role hierachy or sharing rules as needed, like other object records (accounts, opportunities, cases, etc.).
Jen Smith - 1 year ago
Much needed. Surely this must be causing client confidentiality and GDPR issues where organisations are unable to restrict access to email conversations for clients and prospects to users in specific profiles/roles? Having access to an account absolutely doesnt mean a user should see all Activities.
Akansha Bansal - 1 year ago
I agree to what is being asked in the original post. Option 'Private' on Activity must behave as completely Private in terms of visibility as well.
This is a bug which is very confusing as per its terminology as well.
Also when Activty is selected as Private and it becomes readonly for users other than Owner, user can still see all edit and delete actions and gets notified of the insufficient access message only after click. The edit and delete actions must be hidden when the record is readonly for a user.
Overall the whole Privacy setting concept on Task is very misleading as we must have it implemented correctly i.e.
Private Activity must be visible only to Owner and people above hiererchy but we should have option to make it completely Private to owner as well.