Skip to Content
Personal Insights
Author's profile photo Meghan Rosser

Living the ChaRMed Life: How to Create Custom Fields for ChaRM/ITSM and Control Access – Part 2

Hi There!  Thanks for checking out my blog.  As a Solution Manager Architect, I spend a lot of time implementing ChaRM for clients… and with lots of clients come lots of customizing requests!

I will be writing a series of How To’s, based on real world situations and requests.  Hopefully they will benefit you as much as they benefited our clients!

My fifth blog topic is a two-parter, its all about creating custom fields in the CRM UI for ChaRM and ITSM and configuration required to control those custom fields with security authorization, WITHOUT ABAP CODING!

WHAT:  The customer required a field for use in their ChaRM workflows called “Review Date” that they wanted only a certain set of end users to have access to.  They also wanted this field to be searchable and to be reported on.

This need was met by using the Application Enhancement Tool (AET within a Solution Manager 7.2 system SP6. We covered that in the first part of this blog :

https://blogs.sap.com/2019/03/05/how-to-create-custom-fields-for-charmitsm-and-control-access-part-1/

For the second part of this blog, we will conquer the security and configuration work required to restrict this field to only a certain group of end users.

 

HOW:

Prerequisites: 

1.) You must have created a custom field per the steps in Part 1 of this Blog.  We have our custom field, “Review Date”.

2.) This field should only be maintainable by a certain group of end users.  Which we will control using Authorization Check at Field Level configuration available within Solman.

https://help.sap.com/saphelp_crm70/helpdata/en/47/4cd32fe7c56d18e10000000a421138/content.htm?no_cache=true

Perform Configuration Steps for  Authorization Check – Procedure

1.) Create an authorization Group (a type of field group, and consists of a collection of fields )

  • Launch SPRO -> Customer Relationship Management -> Basic Functions -> Authorizations -> Define Authorization Group.

 

  • Enter a name for the Authorization Group
    • Z_CH – ChaRM Auth Group

2.) Assign our custom field to the Auth Group

  • Highlight the line item of the newly created Auth Group
  • click sub menu, Assign Authorization Groups

    • Enter Object name CUSTOMER_H
    • leave Logical Key blank
    • Enter our custom field “ZZFLD0000A” (you can also choose from pop up list)
    • Choose Modus “Change
    • Save your work

 

3.)  Maintain Authorization value for Auth Group

  • In this step we assign an authorization value to our Auth Group, which will then be used when we create a PFCG role and assign to our appropriate users.
  • This activity fills the ill control table CRMM_AUTH_FIELD with these entries and the Authorization check will evaluate this table.
  • Launch SPRO -> Customer Relationship Management -> Basic Functions -> Authorizations -> Maintain Authorizations at Field Level.

 

    • Define the transaction type you wish to control – YMMJ
    • Leave Item Category Blank
    • Dlv Status – Enter *
    • Choose the Auth Group we just created – Z_CH
    • Define a value for Auth. Level – 100

  • Save Work

 

4.) Create a PFCG Role with reference to authorization object CRM_FLDCHK and the Auth Value we have maintained above

  • Launch tcode PFCG to create role
    • New Role is Z_CHARM_FIELD_CHECK

    • Assign auth object – CRM_FLDCHK
      • Activity 45- ALLOW
      • Authorization Group – Z_CH (as defined above)
      • Authorization Level – 100 (as defined above)

      • Save Role
      • Generate Role

5.) Assign this profile to the corresponding user. (we are using Test User ZH_CM_SML)

  • Launch SU01, enter ZH_CM_SML
  • Enter Change Mode
  • Assign newly created role – Z_CHARM_FIELD_CHECK

  • Save

6.) Log into ChaRM with test user ZH_CM_SML to verify we can change the field “Review Date” in a Normal Change – YMMJ

7.) Log into ChaRM with a different test user ZH_DEV_SML who is not assigned the role and verify you cannot change the field “Review Date” in a Normal Change -YMMJ

 

There are a lot of different options to play with regarding the crm_fldchk configuration, this is only the tip of the iceberg.  Maybe a new blog post topic??

 

Thanks for reading, and have fun customizing!

 

Meghan

Assigned tags

      8 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Stephan Wagner
      Stephan Wagner

      Thanks for sharing. I like your HowTo‘s.

      Author's profile photo Meghan Rosser
      Meghan Rosser
      Blog Post Author

      Thanks Stephan!!

      Author's profile photo SMM-BC ANDHI BUDHI
      SMM-BC ANDHI BUDHI

      hi Meghan,

      thank you for the knowledge
      but I have a need to make a custom filed gray field in one phase
      so that the field can only be filled if it is entered in that phase

      example
      In the created field, it becomes a gray field
      in the validation phase, this field can be filled

      Author's profile photo Dinesh Ghanta
      Dinesh Ghanta

      Thanks a lot for Sharing Meghan.

      Author's profile photo Martin Roszak
      Martin Roszak

      hi, thanks for sharing first of all!!

      can this be done also status-depentend? i mean a field that can only be hit in status E0001 and is not editable from E0002?

       

      do we need to create a new business add-in with logic?

      regards

      Martin

      Author's profile photo SMM-BC ANDHI BUDHI
      SMM-BC ANDHI BUDHI

      hi Martin,

      how about your question about this? do you have the solution ?

      Author's profile photo Martin Roszak
      Martin Roszak

      Hi there, i've solved this via the authorization object as mentioned above:

      • Assign auth object – CRM_FLDCHK
        • Activity 45- ALLOW
        • Authorization Group – Z_CH (as defined above)
        • Authorization Level – 100 (as defined above)

      actually in E0001 "NEW" only the Message Processor can change our new field and in E0002 "IN PROCESS" our field cannot be edited. only in "Customer Action" then the Message Processor can edit this field again. So at the end the solution is to create/assign the auth. object (with the specific B_userstats objects and so on)

       

      regards

       

      Martin

      Author's profile photo SMM-BC ANDHI BUDHI
      SMM-BC ANDHI BUDHI

      hi martin, thanks for the explanation

      so you mean all fields in E0002 are not editable if create auth object with b_userstat right?

      doesn't restrict specifically to one field, because in b_userstat can't specifically name a custom field

      I have 3 custom fields,
      in phase E0002 that only 1 custom field cannot be edited, but other custom fields and default fields can still be edited

      do you have a suggestion martin ?

      thanks in advance