Skip to Content

Status Flow of the Request for Change including Approval Procedure and ChaRM Framework

Hi everyone,

starting 7.10 the new Request for Change (RfC) was introduced. This RfC inherits from the CRM standard ITCH (CRM Request for Change) but is widely enhanced.

It uses the approval procedure known from the ITCH in CRM standard.

But there are more possibilities than in CRM standard! The CRM standard approval procedure can be used only once. The ChaRM RfC instead allows you to extend the scope and create further change documents, meaning add further scope items. This can be done if a RfC has created already change documents.

But the new change documents which will be created when the scope is extended have to be approved as well…so we implemented an initialization of an already closed approval procedure. This is done via ChaRM action ‘APP_PROC_INI’.

Check the ChaRM action customizing for that:

customizing 0.jpg


There are further special cases where we had to enhance the approval procedure functions. Imagine, a RfC is in status ‘To be approved’ and the last approver approves the RfC scope the ChaRM Framework is run through to set the status ‘Approved’. But a consistency Check is customized to reset the user status back and not fulifilled. In this case, the approval procedure has to be opened up, again.

This is be done by ChaRM action  APP_PROC_TBA (where TBA is short for ‘To be Approved’).

customizing 2.jpg

The opening-up of the approval procedure is hard-coded in the reset but customers may use this ChaRM action if needed. It just opens up the last approver step(s), setting the last status of the approval steps when the status ‘To be Approved’ was reached.

The logic of the approval procedure can be quite complicated when the scope is extended. Are there already change documents created, is it approved or rejected…when to set which user status.

The IMG activity ‘Set Up Process-Dependent Status Control’ controls which status is set.

customizing 3.jpg

customizing 4.jpg

The last on ‘PRE_APPR’ is used for the normal change for the Preliminary Import process. to define which status to set if the Preliminary Import is approved.

Last but not least, I created an user status flow of the RfC, including an overview of the ChaRM Framework and the Approval Procedure logic.

Approval Procedure overview with user status and ChaRM Framework.jpg

I hope that helps to get some sort of overview of the three players status flow, approval procedure and ChaRM Framework.


You must be Logged on to comment or reply to a post.
  • Hi Michael,

    Thanks for your post.

    In SP04 version, we have customizied the approval procedure with 2 level of approval workflow for Rfc.


    status : To be Approve or Extended Scope

    1st Level Approval :Tech team Approval

    2nd Level Approval :funactional team  Approval.

    Status : Approved.

    So we are not able to control the role with in two level of approval in same status( To be Approved), because once two level of approval is done status change to Approved)

    In Sp05 , whether we get the role restricition for Approval workflow from SAP?

    Plz guide the same.



    • Hi Karthik,

      'Extend Scope' is no additional approval status, it's the status which marks the process to be extended, meaning you already had change documents and need other ones in this RfC because you maybe see that there are dependencies in other systems, f.e. you have adapted some rfc function and now see, this is just for BI and the BI system has to be adapted as well. Then you can extend an already approved RfC and create another change document by approving again. But if you need a two-step approval which sets different status - you have to insert an additional user status and controlling this by authority object B_USERSTAT. The CRM standard approval procedure can only be used for setting one approval status. The approval procedure works like that that you can define different approvers (business roles) but can add additionally during 'Awaiting approval status) further approvers with bps and business partner role. First approval step has to be approved, then you can approve step two, then step three....but as I said, the outcome is just 'approved' or 'rejected' or 'not relevant'. In the first case the user status 'Approved' is set, second case 'Rejected', last case, the approval procedure stays in 'To be approved' until another additional approver is entered and rejects or approves...

      Hope that helps.


      • Hi Michael,

        Thanks for reply.

        As following discussion, In Approval workflow not able to restrict the role for approver.( 2 approval)

        So using the new status creation only we able to restrict the approver role  using  B_USERSTAT.



  • Hello, Michael.

    Could you help me with my problem?

    I need to initialize Approval procedure twice but on different statuses.

    For example:

    "To be approve"    ----APP PROC---> "Approved"   and the second time:

    "To be approve 2" ----APP PROC---> "Approved 2"

    in one RFC document. (there are 4 different statuses of one RFC)

    Could you answer me - is it possible? Let Solution Manager to realize this?

    Thank you in advance,


  • Nice blog, Michael.

    It helps me understand how approval procedure works and the new IMG activity 'Set Up Process-Dependent Status Control'.

    There is some problem with the last picture (the RfC process overview) you attached. I cannot see or download the big picture. Could you please fix it?

    Thanks & Regards,


    • Hi Mike,

      it works for me fine, I do not know why it does not wok for you?

      Have you tried in Citrix? Otherwise mail me, I will sent you the pic. There are two Mike Wangs at SAP ;-),

      Best regards,


      • Hi Michael,

        We are using Solution manager 7.1 SP10,

        Actually what happened in the Scope assignment block without selecting "Document Type" the RFC is Approved.

        So, I want to make a restriction like no one can approved without the "Document type".

        First give the Document Type,Component,Ibase everything in Scope assignment block then the RFC approved

        So,Kindly guide me where should i go and how this restriction create.

        • Hi Abhinash,

          the charm consistency check FOLLOW_ON_GEN_OK checks if the scope and project and iBase is consistent. This check is executed in status 'Being Implemented' before generation of the change documents. You can customize this check as well to status 'Approved' with a reset if you like.


          • Hi Michael,

            I have a bit of a different scenario.

            In my approval procedure, I have 9 approvers, which I segment into blocks of three.

            When the ChaRM is created, it is set to "In Development" and then, the user sets the status to "To be tested" which kicks off the standard workflow. This workflow has been modified, to do three approvals, and then, to set the status to Approved to be tested for UAT.

            The next approver, approver 4 logs on, and manually changes the status to "To be approved for UAT" All of this works fine, however, when the user sets the status, the rest of the approval steps are locked, i.e. greyed out, and, no further approvals can be done.

            Essentially, this is what I need to do:

            Developer sets status "In development"

            Does development, and, then sets status "To be tested"

            Workflow emails first 3 approvers, and, they do their approval

            Workflow changes status to successfully tested for SIT.

            Next user changes status to "To be tested for UAT"

            Workflow emails next 3 approvers, and they do their approval

            Workflow changes status to "Successfully tested for UAT"

            Next user changes status to "To be tested for import to production"

            Workflow emails next 3 approvers, and they do their approval

            Workflow changes status to "Successfully tested for PRD"

            Workflow ends.

            Any ideas?

          • Hi Freddie, you can use the the approval procedure functionality from CRM standard only once. You could reinitiate it via ChaRM action 'APP_PROC_INI' but as you have to define in the status profile which status is the status when the approval procedure is active and when it is closed you have an issue. You can just define each states to one status, not three times.

            best regards,


          • Hi Michael,

            Thanks for getting back to me so quickly.

            I understand what you are saying, and, based on your blog, I followed the steps you outlined, however it now seems to crash.

            I am not specifying implicitly that the approval procedure is finished when I change the status, but, when I use the workflow to set the status, it closes the approval section, and I cannot carry out further approvals.

            If I disable the workflow, or, remove the status change, I can do all the approval steps, and it closes after the last one.

            What alternatives do I have here?

            Many thanks,

            Freddie Botha.

          • Hi Freddie,

            the only alternatives are that the approval procedure just has nine approvers which are deciding all on one status. And when the last one did his last decision, the approval procedure is set to the status where the approval procedure is closed.

            There is one scenario which I never tried, so I do not know how CRM behaves. If you mark more than one user status (f.e. three) with 'C4AP' and let the first group of three approve and then the third approver sets manually the seconf user status and the next three approve and so on. I am not sure CRM does like that and if the approval procedure stays open but there will be for sure be issues when resetting where you would have to adapt our code. If you would replace function AIC_SRQM_RFC_APPROVAL_STAT_EC in the CRM Event Framework with your own function you could mayb automatically set the status after the third and sixth approver has approved. But this would be a dev project and there could me more issues, so I cannot advise to that if you cannot implement it.

            For me it would be the next level to use the CRM Standard approval procedure functionality.

            best regards,