1


Currently when you set the privileges access(read, write) for activities to 'user' only, activities that are owned by other users, and are regarding a record that is owned by the user who has the 'user' access level, can be read and updated by that user, even though the security role shows he/she only has access to activities he/she owns. This is very confusing for customers. I have a few customers that want to restrict the access to owner only, but this can't be do today. I would love to see this changed.

Example: user a has user owned read and edit access on activities. User b is the manager of user a. User b creates a task on a lead owned by user a. User a can see and edit the activities user b created on the lead record.

STATUS DETAILS
Declined

Comments

D

Sentence below should say 'If the lead gets reassigned'

Category: Unified Experience: Search, navigation and performance

D

Thank you for your feedback. This is not a common use case, and we are not planning to consider this at this point

Category: Unified Experience: Search, navigation and performance

D

This is not a bug, this is part of the complex behaviour of the security model and can be customised if you need to. You need to look at the relationship behaviour between the parent entity (Lead in your example) and each activity type (or indeed any other type of child record). In the relationship behaviours section, the "Reparent" behavour for many relationships is set to "Cascade All". This means that if you link a child record to a parent one, it give the owner of the parent record the right to act on the child record as if it was one of their own (this will still limit their ability to do things they can't do to their own activities, such as delete them, if that is what their role says). So if you don't like this feature, change the Cascade behaviour on the relationships where you don't want it. This affects all relationships in CRM. A common example would be Opportunities owned by an internal sales person which would still be visible to the client account manager (owner of the customer Account record). This is helpful in most cases, and where it isn't, you customise it to operate differently. Cascading this down from the Opportunity to the Activities under it makes the same sense - the Account manager wants to know what the internal sales person has done in relation to the Opportunity they own.

Category: Unified Experience: Search, navigation and performance

D

The problem is that is the lead with the activities gets reassigned. They want the activities to go with them, so I can't change the cascading. I just wish that I could restrict the access/privilege level to view/edit to user only, which is what the customer wants, but if you do this in security, it's still allowing the user to view other folks' activities and edit them too. Which I don't think is appropriate behavior.

Category: Unified Experience: Search, navigation and performance

D

You can change the "reparent" behaviour so it does not give the owner of the parent entity more rights over the activities than they should have according to their role (ie only their own). The cascading behaviour for assigning activities when a Lead is assigned can still be configured to whatever you want it to be (typically "Cascade Active" or "Cascade user-owned" work well)

Category: Unified Experience: Search, navigation and performance

D

You can change the "reparent" behaviour so it does not give the owner of the parent entity more rights over the activities than they should have according to their role (ie only their own). The cascading behaviour for assigning activities when a Lead is assigned can still be configured to whatever you want it to be (typically "Cascade Active" or "Cascade user-owned" work well)

Category: Unified Experience: Search, navigation and performance