Within 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, I’d
like to share some ‘expert’ tips and tricks that I’ve 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)
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 you’ve set up two item categories. In both cases,
you’d like a follow-up task to be created in case the item status is
set to ‘Lost’.
·
In only one of the item categories, you’d 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).
Setting up common profiles
In the picture above you see how to work with common
profiles. Creating a common profile is simple: you create 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 profile andthe 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.
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 and have 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 set up this functionality. Because a field
catalog is available, you can use any of the fields you use in pricing to
determine action profiles.
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
In the previous blog I'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
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, we will 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:
·
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 or Start 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 embedded actions' conditions need to be set up per 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.
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.
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.
Using Optimization Rules in action processing
This was the second and last blog on actions. I hope it will
help you in setting up actions, and please let me know if you have any
questions!
