Transcript:
0:05 When working with complex rules, it is
0:07 often desirable to have a log of the
0:08 rules that were executed and what was
0:10 the event and field changes that
0:12 triggered the rules. North52 provides
0:15 detailed trace logging. However, it is
0:17 designed for technical users to use for
0:19 troubleshooting or analyzing a full
0:21 audit of how the rules were executed at
0:23 a system level. They are not intended
0:26 for a customer service representative to
0:28 find information from. A customer
0:30 service rep may have to answer questions
0:32 about why a certain outcome was
0:34 determined by the system. For example, a
0:36 customer may want to query an insurance
0:39 claim and want to understand why their
0:40 claim was
0:41 rejected. By creating a customs rules
0:44 log in Microsoft data versse using the
0:46 North52 business rules engine, we can
0:49 help the customer service rep easily
0:51 answer these questions.
0:53 This is done by creating a separate
0:55 database table to write logs into. The
0:58 logs information can then be presented
1:00 in a chronological view using the out
1:02 ofthe-box grid at both the claim detail
1:05 record and a rollup of all logs at the
1:07 claim level as shown here. This is built
1:10 in North52 using a combination of
1:12 formulas to evaluate the rules and
1:14 create a rules log record. Firstly, on
1:17 create or change of a claim detail, the
1:20 rules determining claim eligibility are
1:22 evaluated and each rule outcome creates
1:25 a message which is added to an inline
1:27 calculation variable called internal
1:29 message. We can see a few examples in
1:32 these decision sheets.
1:35 After all the rules determining the
1:37 claim eligibility have completed, the
1:39 library calculation is executed passing
1:41 in parameters for details of the event,
1:44 field changes and description. The
1:46 library calculation formula is set up on
1:48 the claim detail table so that we get
1:51 context of the information for that
1:52 record when
1:54 executing. As you can see, the decision
1:56 table is very simple. It is set up with
1:59 the sheet options set to use create
2:02 record so that when it executes it
2:04 creates a rules log
2:06 record. The actions columns are the
2:09 fields we update on creation. The claim
2:12 and claim detail lookup fields are set
2:14 from the context of the claim detail
2:16 record and the event field changes and
2:19 description are passed down from the
2:21 execute formula native function used to
2:24 call the library calculation.
2:27 These are referenced using the schema
2:29 name of the claim detail table followed
2:31 by a period then the name of the
2:33 parameter set in the execute formula
2:36 native function. If you'd like to know
2:38 more, please review the associated
2:40 article on our support portal and get in
2:42 touch to see how we can help you with
2:43 your complex business rules requirements
2:45 in the Dynamics platform. Also, please
2:48 don't forget to subscribe to our YouTube
2:50 channel.