Actions in Crm

7/28/2019 Actions in Crm

1/10

Actions in SAP CRM Part 1: Action profiles and

determinationWithin SAP CRM, actions are pieces of logic that are related to a transaction. They are executed

conditionally, either automatically or manually. Examples of actions are: sending out an order confirmation

after saving the order, creating a follow-up task when a certain status has been set, or completing an order

after a period of time. These actions are all available in the standard system, but you can easily create your

own actions and assign them to your own pieces of logic (called: action method) and conditions. Besides

giving a quick overview of what actions are about in this blog, Id like to share some expert tips and tricks

that Ive learned over the years, including action profile determination, a relatively new and little known

functionality that was introduced in CRM 7.0. In this blog, I'll focus on action profiles and action

determination. In the next blog, you'll read all about action conditions.

Action profiles

Actions are defined within an action profile, which in turn is linked to a transaction type or an item category

(see also the next paragraph on determination). In the action, you can set up a number of parameters,including:

1. When the action should be executed (manually/automatically, for instance)

2. Whether the action is partner dependent or not (and, if so, for which partner function)

3. How often the action should be executed

4. What should the action do? Options include:

1. send out a mail/fax/print

2. execute a method (either standard or self-made)

3. trigger an alert
http://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determinationhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determinationhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determinationhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determination


2/10

Example of action details

Common profiles

If you want to reuse action profiles you can setup a common profile and assign it to other profiles. This can

be very helpful if you have some (but not completely) overlapping action requirements for similar objects.

Maybe an example clarifies this:

In a quotation youve set up two item categories. In bothcases, youd like a follow-up task to be created in case the

item status is set to Lost.

In only one of the item categories, youd also like to setup an additional action send out an e-mail too.

You should then create one common profile with the follow-up task action, and create two action profiles in

which this common profile is linked. In one action profile, you also set up a second action for sending out

the mail. Advantages of such a setup with a common profile include:

1. unique actions can be maintained more easily, and

2. additional requirements can be made available with less effort (think of a third item category with yet another

combination of actions).


3/10

Setting up common profiles

In the picture above you see how to work with common profiles. Creating a common profile is simple: youcreate an action profile and flag the Common Profile-flag. You can then select the profile for use in a

normal action profile.

Hint: conditions are setup for the 'complete' profile, i.e. a combination of the actions from the used common

profileandthe actions of the normal action profile. So: you can reuse a common profile in several action

profiles and still have flexibility in the prerequisites (conditions)!

Action profile determination

In older versions of SAP CRM, you could simply assign an action profile to a transaction type or an item

category. Once linked, every new object would include all the actions of the profile that is linked to it, and

that's that. Being quite rigid, this sometimes necessitated the creation of another item category or

transaction type, only because you needed more flexibility. This has been overcome by the introduction of

action profile determination.


4/10

Where to find action profile determination in IMG

The principle is quite simple: instead of linking an action profile directly, you can opt to link an action profile

determination procedure to a transaction type or an item category. It works exactly like a price procedure:

you can use fields from the field catalog to set up condition tables and you set up a number of access

sequences to find the correct action profile(s). Please note the (s) in the last sentence: it is possible to find

multiple action profiles, or to both assign a profile directly andhave one found through the determination.

This can easily be called a small revolution in action customizing in CRM: it is now no longer required to put

all the actions you need in one single action profile! Companies can use action profiles in much more

flexible ways by combining the action profiles they need in specific scenarios. I've used this determination

technique to be able to have one single item category with different action profiles based on the product

that was entered. In the example below you see how this was done. Please note that in this case, we put

the product ID directly into the condition, but you could also use product groups or hierarchy levels to setup this functionality. Because a field catalog is available, you can use any of the fields you use in pricing to

determine action profiles.
http://scn.sap.com/servlet/JiveServlet/showImage/38-74596-152760/action+profile+determination+img.JPG


5/10

Example of determination

The picture above shows how action profile determination works. As usual within SAP CRM, the logic at

runtime needs to be configured the 'other way around':

1. Create or re-use one or more condition types

1. You can create your own condition tables

2. Do not forget to link the condition type(s) to a (new) condition maintenance group

2. Create the conditions

1. This can be done via general condition maintenance

3. Setup an action determination procedure

4. Assign the procedure to the transaction type or item category

Actions in SAP CRM Part 2: Action conditions and

executionInthe previous blogI've discussed how action profiles can be set up and how it is possible to reuse actions

and be more flexible in determining profiles through common profiles and action profile determination.

Now, let's turn to action conditions. Especially if you plan to use a lot of actions in your processes, setting

up conditions the right way will prevent performance problems and allow for future reuse.

Action conditions
http://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-2-action-conditions-and-executionhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-2-action-conditions-and-executionhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determinationhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determinationhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determinationhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determinationhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-2-action-conditions-and-executionhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-2-action-conditions-and-execution


6/10

So, actions have been created and correctly linked (or determined) via the profile. Time to focus when to

execute them. This is done with action conditions. You can base them on attributes from the transaction or

item at hand. Probably most often used are attributes like user or system status, priority, or a milestone.

There's a few tips and tricks here that I'd like to share, but let's start with the difference between the two

types of conditions that are available in SAP CRM.

Schedule vs start conditions

Schedule conditions define when an action is put on the list of executable actions within the object. Once it

is put there, it will be executed as soon as the start condition is met.

By not assigning a schedule condition, the action will be added to the list of executable actions automatically or

manually.

By not assigning a start condition, it is possible to execute the action automatically or manually.

This seems quite straightforward, but there's more to it:

1. Once an action is scheduled, it will be considered during a (background) run of the action selection report. This

impacts performance of the jobs you plan to use.

2. If you want to tirgger actions based on a milestone (e.g., contract end date has passed), you should use a Start

Condition: schedule conditions are only checked if there is a change in the transaction and this means that the contract

end date has long passed before the transaction is 'touched' again and the action is finally executed.

3. You can assign both a schedule and a start condition to one action. In such cases, the start condition is only considered

if the action's schedule condition was fulfilled.

As these points show, there is a conflict here: using too many schedule conditions may impact

performance, but only using start conditions disallows you to plan actions based on milestones. Later, wewill look into the solution that SAP provides for this, and milestone-based actions in general. Let's first

discuss setting up conditions in general, and running a background job.

Setting up action conditions

When you click on Define Conditions in the customizing, you will see the following screen:

Action Condition Maintenance

I won't go into all the details of this screen, but I would like to highlight a few elements:


7/10

with the Technical Names-button you can switch between the description of the action and action profile to the

technical names. This can be very handy if you have non-unique descriptions

setting up conditions is done with an editor in which you link attributes to values with help of expressions.

you can reuse conditions after you created them (you can get an overview of all conditions by cllicking on

theSchedule Conditions orStart Conditions-buttons).o Reusing conditions is particularly useful if you are using common profiles. As highlighted in my blog on action

profiles, common profiles can be used to reuse actions in various action profiles without having to configure them

again and again. These embeddedactions' conditions need to be set upper action profilethat uses them. By reusing

these conditions, you can easily do this.

o Please note that reusing conditions is only possible within:

the same type of condition (schedule / start)

the same item category

o As a general rule of thumb you should consider a naming convention for your conditions (e.g.: [item category]

[description of condition]). Too often you see condition names that tell more about the action that they are linked to,

than what they actually check. Reusing them will then be quite hard!

If you want to setup an action without any conditions, you should still add it in this screen (right top corner). If you

forget this, the action will not work.

Executing actions

Now that the action profiles, its actions and conditions are set up, it is time to see how actions are

executed. As yourecall, there are three moments on which actions are executed:

Immediate processing:as soon as the action should be executed (either by an automatic or a manual trigger), it will be

executed. Typically, an end user is working in the transaction when this occurs.

o This option will lead to wait time for the end user. Therefore, I would only advise it if user feedback is required or if

the action is highly time critical.

Processing when saving the document:when the user or a background process saves the order, the action is executed.

o This option may also impact the end user's experience.

Processing using selection report: during order processing, the action(s) will only be scheduled. Execution will be

done by running the action processing program (transaction code: CRMC_ACTION_JOB).

o Within action customizing you can allow end users to execute the action directly, so they don't need to wait for the

program to run.

o Let's look into the action selection report with some more detail.
http://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determinationhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determinationhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determinationhttp://scn.sap.com/community/crm/blog/2012/11/02/actions-in-sap-crm-part-1-action-profiles-and-determination


8/10

Action selection report

The selection report can be run once or periodically, both in the foreground and the background. If you plan

to run it periodically in the background, you should use set the Processing Settings accordingly

'Processing without dialog': if set, the selected actions are executed directly. This should be set in case of a

background job.

'Restricted Log': will prevent a spool to be created. The action processing logs (that can also be found in SLG1) will

still be filled.


9/10

You then save these entries as a variant and create a new job via SM36 (program =

RSPPFPROCESS). Basically, this sums up how to set up actions. Now I'll focus on some more specific

topics: milestone-based actions and the optimization rule.

Milestone-based actions

Setting up an action that should be executed after a period of time can seem quite tricky at first. This is because a

number of elements should be correctly setup before the action is actually scheduled at the right moment. These

are the things you should get straight:

1. Set up a date profile to calculate your milestone

1. Hint: give different names to the date types and date rules, even though this is not required

2. Be sure to include the standard date rule TODAYTIME in your profile (this will always give the current date+time

when executed; we will need it in the next step)

2. In action condition maintenance, create a start condition that checks whether TODAYTIME is greater than or equal to

the date type

Start condition with milestone

The picture shows an example of a start condition in which a milestone is checked. Please note that

TODAYTIME is shown as &Current Date + Time& when you do not show technical names.

Now let's assume we want to run a hourly background job that executes actions. This would have to check

all start conditions with milestones again and again, even if the milestone will not be reached within another

6 months! That's why optimization rules were introduced.

Optimization rules

With help of optimization rules, you can have the background job calculate when the start condition will be

met. In the example above, in six months time. The system will write this in a table and, the next time the

job is executed, simply skip the start condition because it already found that this condition is not yet

met. This functionality improves performance and requires two configuration activities:

1. In the action condition maintenance, select the date type that you want to use as an Optimization Rule. If you look at

the previous picture, you can already see that an Optimization Rule was linked.

2. In the action job, be sure to flag the Use Optimization Rules option.

1. Note: typically you run this report in a background job. Make sure to set up the variant attributes like in the picture

below. it ensures that each time the job is run, the current date and time are considered.
http://scn.sap.com/servlet/JiveServlet/showImage/38-74608-152812/2+example+optimization.JPG


10/10

Using Optimization Rules in action processing
http://scn.sap.com/servlet/JiveServlet/showImage/38-74608-152813/2+example+optimization+-+job.JPG

Actions in Crm

Documents

Transcript of Actions in Crm