HI @Corey Lile ,

Unfortunately we don’t have such capability by using CRM Access up to now. Something we can look as a future enhancement since this can be a valid request.

However in future, there will be a common feature from our framework team where you can set field level configurations and control the access. So above requirement can be achieve using that as well but we need to check how it will work together with CRM Access. Overall this framework feature is still under investigations.

I can suggest following workaround and need some customizations from your end,

We already have a solution to control users from prevent changing prospect to customer category in customer page. You can follow similar solution to control editing (but I think this will not work together with CRM Access. When you block update from CRM Access then anyway it will raise regardless of following configurations. So probably you can allow update from CRM access and block from following configuration). 

Please note that we haven’t tested this and this is just a suggestion to try out.

If you use Aurena, then you can create a dummy action in the CustomerHandling and grant the relevant users/permission set for that action.

Following is from our category change example,

So there should be an action in CustomerHandling projection side named “CheckCreateCategoryCustomer”. (you can add a different named one).

And please refer the code in Customer_Info_API package (Customer_Info_API.Check_Update___) where we have checked whether user has the permission to access this function and if not system will raise an error.

So similar to this you can check whether the user is updating a customer category customer record then raise an error if that user doesn't have access to the dummy function. but it will allow to edit prospect category customer record.

If you use IEE, then it will also have similar code as above and you can control by grant permissions to the function.

Best regards,

Masheesh

You could create a new user role in your CRM system that grants sales reps access to make b2b data enrichment changes at the Category = Prospect level while still restricting their ability to make changes at the Category = Customer level. You could then assign this new user role to your sales reps as needed. You could modify the existing user roles in your CRM system to grant sales reps access to make changes at the Category = Prospect level while still restricting their ability to make changes at the Category = Customer level. This would require a more granular approach to permissions, but could be more efficient if you have a large number of sales reps. You could use field-level security to restrict access to specific fields within your CRM system. This would allow you to grant sales reps access to make changes at the Category = Prospect level while still restricting their ability to make changes to specific fields at the Category = Customer level.