C4C Account authorization

[danielepiazza]

Dears,

we are integrating Account from SAP ECC. Users cannot change data to any type of customer. In general, customer master data, can be created and maintained only in SAP ECC and transferred to C4C.

In C4C, user must have the possibility to manage contacts (not integrated with SAP ECC) and attachment or all information that are only relevant to C4C (marketing attributes) related to the Account.

To avoid the possibility to change Accounts we set as Write Access - No Access, but it's not possible to add or delete new contact directly from Customer view or add attachment.

Does exist a standard solution to provide what has been described above?

Daniele

[Vishwas1 · Accepted solution]

Dear Danielle,

Going by your question, I understand that you are expecting users to add contacts and attachments in accounts but restrict them from modifying any other data. Hence, Write Access = No access at business role will not serve your purpose. I would recommend you to make below changes in adaptation mode in the Master Layout.

• Make all the fields in account read-only
• Hide Add / New buttons in all the facets except the ones in Contact and Attachments facets as per your requirement.
• Disable any other features as desired.

Post this, enable Write access = Unrestricted at business role level. I understand this is time consuming but a one-time activity and will help you achieve your requirement.

Hope this helps. Please comment in case you face any hurdle or if you found some other way to achieve this.

Regards

Vishwas

[danielepiazza · Accepted solution]

Hi Vishwas,

I'm already aware about this kind of solutions, I try to not implement it but if adjust the layout or implement rules it's the only way to achieve the result we will do it.

I'm only surprised that this is something that all customer, at least mine, required and in this year SAP didn't provide a standard solutions... by the way thank you for support.

Regards,

Daniele

[Vishwas1 · Accepted solution]

Dear Daniele,

1) If the requirement stated by you mentioned that the users should not access anything in accounts, we could have considered business role with Write access = No access.

2) If the requirement stated by you mentioned that the users should access everything in accounts, we could have considered business role with Write access = Unrestricted.

But the requirement demands to have access to some aspects and no access to some other aspects of account. Hence, the requirement is not straight forward to use the standard functionality. We had a similar requirement in one of the projects and adopted the rule builder functionality. Just out of curiosity, May I ask you why do you not want to implement this solution?

I will also check with my friends and colleagues to see if there is a better way to achieve this.

Regards

Vishwas

[danielepiazza · Accepted solution]

Hi,

I don't like this solution, that I already implemented in other customer ;D , just because creates a lot of layouts or rules can reduce system performance.

[Juliuspereira]

Hi Daniele,

As far as I know, when the account object's write access is set to no access, you cannot add or create new contacts from the Accounts View. You also cannot assign attachments as all that would need a save action to save the changes, but the 'no access' will not permit a save.

The only things that you can do with write access set to no access is create transactions (activities, leads, opportunities etc.) since these do not need a save of the account but a save of the transactions only.

There a few options, though you might not like any of them. 🙂

1. Create seperate business roles for Account Write Access = unrestricted and seperate roles for account Write access = No access and assign them accordingly.

2. Set the Account Write Access = unrestricted and control all that the user should not be able to edit, using KUT.

3. Set the Account Write Access = unrestricted and control all that the user should not be able to edit, using sdk code.

Sorry for not having a better answer.

Julius