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 :
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.
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.
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)
- Assign auth object – CRM_FLDCHK
- 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
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!
Thanks for sharing. I like your HowTo‘s.
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
In the created field, it becomes a gray field
in the validation phase, this field can be filled
Thanks a lot for Sharing Meghan.
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?
how about your question about this? do you have the solution ?
Hi there, i've solved this via the authorization object as mentioned 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)
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
Do I understand correctly?
Have you restricted editing of a certain field in a certain status? And other fields in this status are changeable?
If so, please share your experience.
I will be very grateful to you.
Thank you so much for sharing this post, super insightful.
Do you perhaps know how we can add that custom field into the mail notification as an attribute without doing ABAP and implementing BADI's?
Looking forward to your response.