Skip to Content

Specifying future-proof enhancements in SAP CRM with help of parameters

As a functional consultant, you probably write functional specifications now and then. Even though the SAP CRM solution offers many ways to customize processes, some enhancements are needed to fulfill the few business requirements that cannot be met by standard functionality. With help of business add-ins or the possibilty to link your own function modules in customizing, SAP CRM can of course also cater for that. But SAP CRM cannot ensure that these enhancements are built in a future-proof way.

Only too often I encounter developments that contain hardcoded values or that apply to the system as a whole. Before we go over the most important options to overcome this in more detail, let’s first quickly look at the disadvantages a customer might encounter if enhancements are built in a rigid or hardcoded way. Examples of disadvantages are:

  • A change in customizing requires a change in coding
  • If new business units want to use the system, but do not want your specific enhancement,  a change in that coding is needed
  • Once-built logic tends to be forgotten, leading to additional costs when extending or upgrading the system later

So, how can we ensure that enhancements are controllable functionally? With this blog I aim to shed some light on the little-known yet highly powerful parameter options that are standard available in SAP CRM.


Parameters can be used to steer logic: programmers can check the value of a parameter before apart of the logic is processed. A parameter can be a simple on/off switch or it can contain a value that would be hard-coded otherwise.

Available parameter types

User parameters


If you want certain logic to be only available to certain users, this is the way to go. You can setup additional parameters to your own liking


Possible to switch on/off or adapt the logic on the lowest possible level: the user. More work to setup and maintain though.


You can create your own user parameters via SM30 in table TPARA. From then, you can set the value for a user through SU3 (your own user) or SU01 (any user).

0113-SU3_1.JPG 0113-SU3_2.JPG

What to put in the specification?

From the coding, the parameters and values of a user can be retrieved. Values are stored in table USR05.

Organizational attributes


You want certain logic, that might be executed in the background, only to apply to (e.g.) certain sales organizations.


Can be setup on high level and then inherited to the lowest, where it can be overwritten if wanted. Downside is that the organizational model should be maintained for this.


You setup your own attributes in table T77OMATTR through SM30. First enter your new attribute (see screenshot). If you enter a description and hit enter, the table and field names are defaulted (SAP delivers a standard table in which all these attributes are saved).


You then link the attribute to the scenario (Sales, Service, or Marketing) and to the object type (for instance O for Organizational Units). You can even setup inheritance from higher- to lower-level objects. This way can you also setup attributes for positions and have those defaulted from the sales organization to which they belong, and overwrite the value if needed. The new attribute is then available in the list of attributes.

What to put in the specification?

You can add the hint to use function module RH_OM_ATTRIBUTES_READ to retrieve all attributes, including your own (if maintained, of course).

WebUI parameters


Your end users work through the webUI and you would like specific logic to apply only to certain business roles.


You can assign parameter values to (big) groups of users rightaway. Needs to be customized and transported though, and only suitable for processes running or initiated in the webUI.


Parameters can be created through customizing (IMG > CRM > UI Framework > Technical Role Definition > Define Parameter). You assign the parameters and their values to a parameter profile. This profile can then be linked to one or more business roles as a function profile (ID = PARAMETERS, vallue = the parameter profile).


What to put in the specification?

There are standard possibilities to retrieve the business role that the user is logged on for.

Other parameters

Besides the parameter types discussed above, you can also think of other parameters in the system. Example include marketing attributes (freely definable fields in the account), and container parameters in action definitions (more information about actions can be found in my blogs). These will not be described in this blog.

Own table(s)


If you have more complex requirements, it can be an option to define your own ‘customizing’ table. Many customers have one in which they can dynamically add parameters to their coding.


Much more ‘steering’ possibilities, but has the risk of being hard to understand.


Often, these tables are really ‘for insiders only’, and you know what tends to happen with insiders: they leave the company, forget they ever built it, whatever… The best structure I’ve seen was a combination of two tables: one in which the link between the object (FM/report/class, for instance) and the parameter was given, and another table with the actual parameters and their values. All programmers were required to use the first table to retrieve the parameter, and this ensured the tables were filled correctly. This enables every new kid to quickly see where what parameters are used.

Which to pick, and how to use them?

Which option you decide to use for the enhancement that you want to have built depends on how you want to limit the logic now, or in the future. The more the SAP CRM solution is used, the more these parameter options will be used. As a company, you should consider setting up guidelines for projects and changes to only build enhancmenets using the parameter options you have chosen based on your company’s roadmap (think of: future roll-outs or additional functionalities). By using these parameters in a wise and consequent way, companies can benefit from the enhancement possibilities SAP CRM offers without having the risk that they cannot be managed anymore.

You must be Logged on to comment or reply to a post.
  • I think you overlooked the fact that if you are CRM 7.0 EHP1, you could convert all your business rules into the BRF+ custom framework.  It’s more work, but once setup then all your logic could be maintained through business rules instead of any of these methods above. 

    I would strongly recommend against SET/GET parameters due to the fact those can only be maintained by an SAP Security group as most CRM users don’t use the SAP GUI and are prone to typo’s and manual failure.  I honestly think that custom tables are actually the best route if you don’t use BRF+ and if you use the Rapid Application Builder that is available in EHP1, then you could allow users to maintain the contents as needed.

    That being said and seeing “logo” next to your name, I think SAP should extend the AET in EHP3/4 to generate BRF+ rule evaluations along the one-order framework.  In other words the tool could generate a BRF+ context evaluation along various points as needed and you tell the generator what the context should be and what errors messages should be raised if the rule fails. 

    The other problem is you still have to write code in the proper places that evaluates your logic.  IMHO this is where most of the problems with the “not know where bodies are buried” comes into play.  The actual Z-table maintenance is not as much of the issue, but rather how is stuff used.

    Take care,


    • BRF+ is indeed a good addition to the options mentioned, you’re right. With respect to user parameters, the fact that they can only be maintained by the authorizations department can also be a reason to use them: they’re below the surface and could be made part of the setup of a new user. But I do agree that tables are the most elaborate option, provided that it is consistently used.



      • IMHO after supporting SAP CRM productively for the last eight years, asking the Security group to add more steps to the user setup procedure beyond user id creation and role assignment is a recipe for disaster.  The problem is that most security tools for user cretion focus on role assignment and not parameter ID mainteance.

        Even worse is that if Security group manually maintains the parameters and then makes a typo, it will be yet another troubleshooting issue on trying to fix that.  It just doesn’t scale up properly when you have more than 100+ users on your CRM system.  That being said I like the concept in theory, but my production support experience tells another story.

        Take care,


  • Hi Joost,

    great article, and although Stephen has a good point about the “security” aspect and maintenance, I think it’s still a viable option to use these methods, depending on the nature of the company and ‘maturity’ of the departments involved in support of the SAP systems from CRM support to Authorization support.