Using the Handle Native Change To Account Attributes Workflow

Whenever Waveset detects a native change (that is, a change not performed through the Waveset) to the values of an auditable attribute of a resource account, it responds by running the handleNativeChangeToAccountAttributes workflow. This workflow is associated with this System Configuration object attribute:

<Attribute name='process'>
   <Object>
     <Attribute name='handleNativeChangeToAccountAttributes' value='Audit Native
                      Change To Account Attributes'/>
   </Object>
</Attribute>

This workflow logs the native change events to the event log if you have enabled the Changes Outside Lighthouse audit filter. Otherwise, Waveset ignores the event. Warning: Be careful which methods you call from any workflow that replaces the default workflow listed above.

Because Waveset launches this workflow whenever a resource account fetch reveals a native change, it must not invoke any method or workflow that would trigger another fetch of the same resource account. For example, an infinite loop will result if you call any workflow services method that assembles the User view: getView(User), checkoutView(User), and possibly checkinView(User).

The fact that Waveset handles each native change by running a workflow allows you to hook the native change event, and to handle that native change however you see fit by replacing or adding to the default native change workflow. For example, you might choose to send email to an administrator or a user, to record the event in a database, to queue an update that would back out the native change, or even to pull that native change into Waveset and push it back out to the other resources.