Dovetail RuleManager Documentation

Specific Differences

Additional details regarding specific differences between Dovetail RuleManager and Amdocs Rulemanager.

Action Calendars

Calendars are used in business rules so that actions take place relative to the specified business calendar.

Baseline action calendars include Elapsed Time, Customer Business Hours and Support Business Hours.

Amdocs Rulemanager	Dovetail RuleManager
If the calendar of the action cannot be found, then the action is not processed.	If the calendar of the action cannot be found, then Elapsed Time is used for calculating the action escalation time.

Case Insensitive Property Names

Amdocs Rulemanager	Dovetail RuleManager
On Oracle databse systems, property names (table_prop_name.prop_name) are case sensitive. This allows seemingly duplicate property names to be defined, which can lead to confusion.For example, for the subcase object (obj_type = 24), two different properties can be defined: Site Name site name This can lead to confusion as to which one is actually being evaluated.	Property names are treated as case insensitive. RuleManager will use the first one it finds in the database, regardless of the case of the property name. For example, for the subcase object (obj_type = 24), two different properties can be defined: site name Site Name RuleManager will use the first one it finds in the database.

Condition Evaluation

Amdocs Rulemanager	Dovetail RuleManager
When RuleManager reads a scheduled action timebomb from the table it re-evaluates its conditions. If the conditions have changed and are no longer true, the timebomb is ignored and deleted and any other timebombs created by the same rule are deleted. If the timebomb is a repeating timebomb it is not fired and the timebomb is removed. As would be expected, it the condition is re-established, the timebombs do not reappear. For example, consider a rule in that has three actions when a case is created with severity equal to Urgent: Notify me in 24 hours Notify my supervisor in 48 hours Notify the owner every 20 minutes for the next 24 hours When a case is created with severity equal to Urgent, three timebombs get created, one for each of the actions. If I accept this case and lower the severity to medium, when the 20 minute mark happens all three timebombs are deleted from the database. Of course if I say "oops - misset the Severity" - and change it back to Urgent, the timebombs do not get remade (A nice way to prevent your supervisor from being notified :-) )	Rather than future timebombs being deleted, the conditions will be re-evaluated at the expiration time of these future timebombs. Conside the same rule example to the left. When a case is created with severity equal to Urgent, three timebombs get created, one for each of the actions. If I accept this case and lower the severity to medium, when the 20 minute mark happens, the rule condition evaluations will occur, which will evaluate to false, and the notification will not occur. If I say "oops - misset the Severity" - and change it back to Urgent, the timebombs will still be there, thus 20 minutes later the owner notification will happen, as will the 24 hour and 48 hour notifications.

Amdocs Rulemanager

Dovetail RuleManager

When RuleManager reads a scheduled action timebomb from the table it re-evaluates its conditions. If the conditions have changed and are no longer true, the timebomb is ignored and deleted and any other timebombs created by the same rule are deleted. If the timebomb is a repeating timebomb it is not fired and the timebomb is removed. As would be expected, it the condition is re-established, the timebombs do not reappear.

For example, consider a rule in that has three actions when a case is created with severity equal to Urgent:

Notify me in 24 hours
Notify my supervisor in 48 hours
Notify the owner every 20 minutes for the next 24 hours

When a case is created with severity equal to Urgent, three timebombs get created, one for each of the actions. If I accept this case and lower the severity to medium, when the 20 minute mark happens all three timebombs are deleted from the database. Of course if I say "oops - misset the Severity" - and change it back to Urgent, the timebombs do not get remade (A nice way to prevent your supervisor from being notified :-) )

Rather than future timebombs being deleted, the conditions will be re-evaluated at the expiration time of these future timebombs.

Conside the same rule example to the left.

When a case is created with severity equal to Urgent, three timebombs get created, one for each of the actions. If I accept this case and lower the severity to medium, when the 20 minute mark happens, the rule condition evaluations will occur, which will evaluate to false, and the notification will not occur.

If I say "oops - misset the Severity" - and change it back to Urgent, the timebombs will still be there, thus 20 minutes later the owner notification will happen, as will the 24 hour and 48 hour notifications.

Email from Address

Amdocs Rulemanager Dovetail RuleManager

Amdocs Rulemanager	Dovetail RuleManager
When an email is sent from the system, Rulemanager uses a commitment template (com_tmplte) to determine the format and details of the actual email. These templates can be configured to specify a from address. For example, when sending an email out, the send_email_about_obj com_tmplte is used. This template looks like: TO: , FR: RE: Regarding Case Number Notice that the com_tmplte has FR: token in it. When the Amdocs Rulemanager sends an email, it does not interpret the FR: token as a From token - instead, it simply includes the FR: token and value in the email body. In order for Amdocs Rulemanager to send email, it connects to a Microsoft Outlook email client, and it connects as a particular mail account user. Whenever Amdocs Rulemanager sends email, it uses that mail account user as the from address. For example, if the Outlook mail account is rulemanager@company.com, then all emails (including Log Emails, Commitment Escalations, and Business Rule Actions) will have a from address of rulemanager@company.com. So, putting it all together, a Log Email sent from a case will look something like: `TO: customer@company.com, cc_customer@company.com CC: FROM: rulemanager@company.com SUBJECT: regarding Case Number 12345 BODY: FR: sender_login_name This is the actual message body typed in by the user.` Notice that FR: sender_login_name is included in the body, and the from address is always from the rulemanager email address.	RuleManager has the ability to honor the FR: token in the template or not. It can behave exactly as Amdocs Rulemanager does, or it can function as many customers prefer. For example, assuming the following configuration settings: `EmailServiceConfig.UseDefaultFromEmailAddressForAllMessages = false` `EmailServiceConfig.DefaultFromEmailAddress = rulemanager@company.com` Then a Log Email sent from a case will look something like: TO: customer@company.com, cc_customer@company.com CC: FROM: sender_email_address@my_company.com SUBJECT: regarding Case Number 12345 BODY: This is the actual message body typed in by the user. Notice that the from address is the actual sender of the email, and the body does not include FR: sender_login_name. Of course, if you prefer to have it the "old" way, you can. For example, assuming the following configuration settings: `EmailServiceConfig.UseDefaultFromEmailAddressForAllMessages = true` `EmailServiceConfig.DefaultFromEmailAddress = rulemanager@company.com` Then a Log Email sent from a case will look something like: `TO: customer@company.com, cc_customer@company.com CC: FROM: rulemanager@company.com SUBJECT: regarding Case Number 12345 BODY: This is the actual message body typed in by the user.` Notice that the from address is the rulemanager email address, and the body does not include FR: sender_login_name.

When an email is sent from the system, Rulemanager uses a commitment template (com_tmplte) to determine the format and details of the actual email. These templates can be configured to specify a from address.

For example, when sending an email out, the send_email_about_obj com_tmplte is used.
This template looks like:

TO: , FR: RE: Regarding Case Number

Notice that the com_tmplte has FR: token in it.

When the Amdocs Rulemanager sends an email, it does not interpret the FR: token as a From token - instead, it simply includes the FR: token and value in the email body.

In order for Amdocs Rulemanager to send email, it connects to a Microsoft Outlook email client, and it connects as a particular mail account user. Whenever Amdocs Rulemanager sends email, it uses that mail account user as the from address. For example, if the Outlook mail account is rulemanager@company.com, then all emails (including Log Emails, Commitment Escalations, and Business Rule Actions) will have a from address of rulemanager@company.com.

So, putting it all together, a Log Email sent from a case will look something like:

TO: customer@company.com, cc_customer@company.com
CC: 
FROM: rulemanager@company.com
SUBJECT: regarding Case Number 12345
BODY:
FR: sender_login_name
This is the actual message body typed in by the user.

Notice that FR: sender_login_name is included in the body, and the from address is always from the rulemanager email address.

RuleManager has the ability to honor the FR: token in the template or not. It can behave exactly as Amdocs Rulemanager does, or it can function as many customers prefer.

For example, assuming the following configuration settings:

EmailServiceConfig.UseDefaultFromEmailAddressForAllMessages = false
EmailServiceConfig.DefaultFromEmailAddress = rulemanager@company.com

Then a Log Email sent from a case will look something like:

TO: customer@company.com, cc_customer@company.com
CC:
FROM: sender_email_address@my_company.com
SUBJECT: regarding Case Number 12345
BODY:

This is the actual message body typed in by the user.

Notice that the from address is the actual sender of the email, and the body does not include FR: sender_login_name.

Of course, if you prefer to have it the "old" way, you can.

For example, assuming the following configuration settings:

EmailServiceConfig.UseDefaultFromEmailAddressForAllMessages = true
EmailServiceConfig.DefaultFromEmailAddress = rulemanager@company.com

Then a Log Email sent from a case will look something like:

TO: customer@company.com, cc_customer@company.com
CC: 
FROM: rulemanager@company.com
SUBJECT: regarding Case Number 12345
BODY:
This is the actual message body typed in by the user.

Notice that the from address is the rulemanager email address, and the body does not include FR: sender_login_name.

Process Manager

Amdocs Rulemanager	Dovetail RuleManager
As of Clarify version 12, Amdocs added a new product to their ClarifyCRM suite: Process Manager. Process Manager allows customers to automate their business logic. These processes can be invoked via RuleManager, using a business rule. These business rules use a new message type: Run Service. In addition, then can use a Business Rule Event Creation Time of Process/Action Duration and a Business Rule Calendar of Process Instance.	Integration with the Amdocs Process Manager is not supported, nor are its associated constructs. Business Rule Actions with a Message Type of Run Service are not loaded from the database, and thus are essentially ignored. Business Rule Event Creation Times of Process/Action Duration will be logged as an error, and that particular rule action will be ignored. Business Rules using a calendar of Process Instance will be defaulted to Elapsed Time. An error will also be logged in this situation.

Amdocs Rulemanager

Dovetail RuleManager

As of Clarify version 12, Amdocs added a new product to their ClarifyCRM suite: Process Manager. Process Manager allows customers to automate their business logic. These processes can be invoked via RuleManager, using a business rule. These business rules use a new message type: Run Service. In addition, then can use a Business Rule Event Creation Time of Process/Action Duration and a Business Rule Calendar of Process Instance.

Integration with the Amdocs Process Manager is not supported, nor are its associated constructs.

Business Rule Actions with a Message Type of Run Service are not loaded from the database, and thus are essentially ignored.

Business Rule Event Creation Times of Process/Action Duration will be logged as an error, and that particular rule action will be ignored.

Business Rules using a calendar of Process Instance will be defaulted to Elapsed Time. An error will also be logged in this situation.

Email Attachments

Amdocs Rulemanager	Dovetail RuleManager
Amdocs Rulemanager does not have functionality.	RuleManager includes attachments for emails initiated via a LogEmail action. The application taking that action, such as Dovetail Agent or the Clarify Client, is responsible for relating the LogEmail (table_email_log) to the attachment(s) (table_doc_inst). Because RuleManager will only attach files that it has access to, we recommend that the path to the attachment is a UNC path such as "\server\path\file.ext". If RuleManager cannot access an attachment, the email will still be sent without the attachment. RuleManager will log an error when this situation occurs. Refer to the logging section for more information on logging configuration.

Amdocs Rulemanager

Dovetail RuleManager

Amdocs Rulemanager does not have functionality.

RuleManager includes attachments for emails initiated via a LogEmail action. The application taking that action, such as Dovetail Agent or the Clarify Client, is responsible for relating the LogEmail (table_email_log) to the attachment(s) (table_doc_inst). Because RuleManager will only attach files that it has access to, we recommend that the path to the attachment is a UNC path such as "\server\path\file.ext". If RuleManager cannot access an attachment, the email will still be sent without the attachment. RuleManager will log an error when this situation occurs. Refer to the logging section for more information on logging configuration.

Rule Properties that traverse a MTM or OTM relation

There are differences in how Dovetail Rulemanager and Amdocs Rulemanager handle when a rule property traverses through a MTM (Many-To-Many) or OTM (One-To-Many) relation.

Rule Properties

A rule property typically resolved to one piece of data.

For example, consider a property that is the site name for a case. The path to resolve this would be case_reporter2site:site_name.

This would resolve to one piece of data, which is the site name.

If a rule property traverses a MTM or OTM, it's possible that the end result would be many pieces of data, not just one.

For example, a solution can be related to many change requests (bugs).

Given a property for a solution named "Related CR IDs", with a property path of probdesc2bug:id_number, this could resolve to multiple ID numbers.

There is a difference in how Clarify Rulemanager resolves these properties versus how Dovetail Rulemanager resolves these properties.

Amdocs/Clarify Rulemanager

If the rule property has a subtype of "Property", then Clarify Rulemanager will not properly resolve the property.

It will return [property name = ???]

The Rulemanager log will show the details of the evaluation:

Info Verbose 1968 0 Mapping 'Related CR IDs' to path… 'Related CR IDs' is a Property Name.

loc_dbg_print: Found string 'Relation '%s' in the relation path cannot be traversed.

Info Medium 1968 0 Property [Related CR IDs] evaluated to '[Related CR IDs=???]'

However, there is a workaround. Clarify Rulemanager can resolve a MTM if the rule property has a subtype of "Alias".

This is typically used for Business Rule Recipient Aliases, i.e. who to notify.

Changing the rule properties subtype to alias allows Clarify Rulemanager to properly resolve it as a single string, with each piece of data separated by a space.

If the solution was related to multiple CRs (23 and 24), then the result would be "23 24" (without the quotes).

The Rulemanager log will show the details of the evaluation:

Info Verbose 1968 0 Mapping 'Related CR IDs' to path… 'Related CR IDs' is a Alias Name.

Info Medium 1968 0 Property [Related CR IDs] evaluated to '21 23 '

As you can see, if its an Alias, it is properly evaluated.

This indicates that the property evaluation mechanism within Clarify Rulemanager is different depending on the subtype (alias or property). Unexpected, but true.

There is one small downside to this workaround - since your property is now defined as an alias, it will not show up in the list of variables on the Business Rule Message Form. And it will show up in the list of Business Rule Recipients on the Business Rule Actions form.

Dovetail Rulemanager

Dovetail Rulemanager simply creates a single string, with each piece of data separated by a space.

Given a property for a solution named "Related CR IDs", with a property path of probdesc2bug:id_number, this could resolve to multiple ID numbers.

If the solution was related to multiple CRs (23 and 24), then the result would be "23 24" (without the quotes).

This works the same whether it's a property or an alias.

Additional Information

Refer to Dovetail Solution 544 for additional information on this topic.

focus:path:field notation in email templates

When outgoing emails are sent, Rulemanager combines the data from the email_log record with a template, specifically the com_tmplte with a title of send_email_about_obj

To include data from the email_log record into the template, use the FOCUS.field syntax. For example, FOCUS.recipient will resolve to table_email_log.recipient.

Clarify/Amdocs Rulemanager

With Clarify/Amdocs Rulemanager, you can use path traversals, such as:

<FOCUS:case_email2case:case_reporter2contact:first_name>

which will traverse from the email_log to the case, from the case to the contact, and resolves to the contact's first name.

But, this causes an issue if you use log email from multiple workflow types, i.e. if you use cases and subcases.

This is because the single send_email_about_obj template is used by log emails for many workflow types, including cases and subcases.

This syntax would resolve for cases, but wouldn't for subcases.

So, any log emails for subcases would contain that text as a literal string, which would not be desired.

If you only use cases, then you can probably get away with this.

Dovetail Rulemanager

With Dovetail Rulemanager, the <focus:path:field> notation is not supported.

Instead, you can use rule properties, such as [Case Title] or [Contact First Name].

These properties would need to be defined as standard rule properties.

This blog posts discusses this in detail, and provides sample rule properties and a sample send_email_about_obj template:

http://clarify.dovetailsoftware.com/gsherman/2010/11/18/use-rule-properties-in-your-outgoing-emails/

A rule property that doesn't resolve properly is ultimately resolved to an empty string, not a literal.

For example, given a send_email_about_obj template that contains this:

Title: [Case Title] [Subcase Title]

For cases, the [Subcase Title] property wouldn't resolve, so it would be blank.

And for subcases, the [Case Title] property wouldn't resolve, so it would be blank.

Hence, you get the output that you want.

Additional Information

Refer to Dovetail Solution 658 for additional information on this topic.