Is there a way to limit user access based on a specific drop down option within a field? Or just the field itself?

We have a particular field and we only want certain users to have access to those leads that have a specific option marked in that particular field. Any way to accomplish this? In Role Management I'm only seeing options to block users from the entire field, not within a choice in a field. For instance if we have Lead Source as a field with drop down options A, B, C and D. I want to be able to create a role where any user assigned to that role ONLY has access to leads marked with option C chosen in that particular field. Any help is greatly appreciated. 

Parents
  • Hi Dawn,

    I had a similar desire and I agree with Patrick that the way to handle it is with Teams.  I have a simple process that changes the Team of a record when it is saved based on the drop-down value of a field in the record (in a few of the modules actually). 

    Bud Hartley | Cape Foulwind, NZ (and Oregon, USA)

  • Bud this sounds like what I would need to do since all of our users cannot be classified within that same team if that selection doesn't apply. Could you give me more info on that? 

  • Hi Dawn, Sure, I'm happy to help.  Please don't be offended by the "basics" that I will repeat here - you probably know it, but I want to be clear in what I've done and how I approached it.

    Basic organization:

    What records a user can access is defined by the Team - My teams are basically Sales Territories - most of them are geographic (Postal Code), but some are Special Customer Account Teams, and Product Specialities that overlay the geographic Territories.

    What a user can do with a record is defined in the Role.  In my case, I have Roles for things like Sales, Customer Service, Administration, Sales Assistant, the various manager roles and other functions like Purchasing, Credit Department, Warehousing, etc.

    Drop-Down Lists:

    I have a number of these that include things like Record Type, Credit Rating, Sales Territory Code, and even "Company Code" since we are actually four companies under the same ownership that shares one Sugar implementation.

    The challenge:

    Since everyone in the sales role can do the same things to a record for which they have access, the only way to prevent them from accessing it is to have in in a Team for which they are not a member.

    THEREFORE, I have simple Business Processes that are run when a record changes (set for all record changes, and I have a start in the process for new records too).  The criteria for the start is set for when the drop-down value "changes to" a particular value, and the next step is do a simple record change for the Team to the desired value, and end the process.

    NOTE: Some day I hope we will be able to use Teams in a Business Rule - I submitted that request some time ago.  In the mean time, it has to be a record change to alter the team.

    I've simplified the explanation of what I did.  In reality I have a single process that fires whenever the drop-down value changes (instead of a separate one for each drop-down value), and the next step is to take a path based on that the new value is in the field.

    At the risk of overkill: All Sales Role users have the same authority, and all sales assistants have the same capabilities.  Based on a drop-down value, the account (or contact, etc.) is reassigned to a different Team - P.S. Obviously you do not lose the audit history when the Team changes.

    I hope this helps.

    Bud Hartley | Cape Foulwind, NZ (and Oregon, USA)

Reply
  • Hi Dawn, Sure, I'm happy to help.  Please don't be offended by the "basics" that I will repeat here - you probably know it, but I want to be clear in what I've done and how I approached it.

    Basic organization:

    What records a user can access is defined by the Team - My teams are basically Sales Territories - most of them are geographic (Postal Code), but some are Special Customer Account Teams, and Product Specialities that overlay the geographic Territories.

    What a user can do with a record is defined in the Role.  In my case, I have Roles for things like Sales, Customer Service, Administration, Sales Assistant, the various manager roles and other functions like Purchasing, Credit Department, Warehousing, etc.

    Drop-Down Lists:

    I have a number of these that include things like Record Type, Credit Rating, Sales Territory Code, and even "Company Code" since we are actually four companies under the same ownership that shares one Sugar implementation.

    The challenge:

    Since everyone in the sales role can do the same things to a record for which they have access, the only way to prevent them from accessing it is to have in in a Team for which they are not a member.

    THEREFORE, I have simple Business Processes that are run when a record changes (set for all record changes, and I have a start in the process for new records too).  The criteria for the start is set for when the drop-down value "changes to" a particular value, and the next step is do a simple record change for the Team to the desired value, and end the process.

    NOTE: Some day I hope we will be able to use Teams in a Business Rule - I submitted that request some time ago.  In the mean time, it has to be a record change to alter the team.

    I've simplified the explanation of what I did.  In reality I have a single process that fires whenever the drop-down value changes (instead of a separate one for each drop-down value), and the next step is to take a path based on that the new value is in the field.

    At the risk of overkill: All Sales Role users have the same authority, and all sales assistants have the same capabilities.  Based on a drop-down value, the account (or contact, etc.) is reassigned to a different Team - P.S. Obviously you do not lose the audit history when the Team changes.

    I hope this helps.

    Bud Hartley | Cape Foulwind, NZ (and Oregon, USA)

Children
No Data