Design Policy Workflow

Policy Designer: Design Policy Workflow

This workflow describes the process for designing and validating policies. Policies can be used to automate APM workflows by generating email alerts, as well as creating, deleting, or updating records used in the other workflows based on the input values and policy logic.

In the following workflow diagram, the blue text in a shape indicates that the corresponding description has been provided in the sections that follow the diagram. For more information, refer to the Interpreting the Workflow Diagrams topic in the APM Product Workflows documentation.

Note: For information on the personas associated with a APM module, refer to the APM Product Workflows documentation.

ASM (Asset Strategy Management)

Persona: Analyst (Strategy)

During implementation of an Asset Strategy, the Strategy Analyst may identify policies needed to address Strategy Actions. For example, policies can calculate health indicators, create event logs, and/or provide automated decision support. Actions may be implemented as policy instances or health indicators that are updated by a policy.

Create / Modify Policy?

Persona: Analyst (Strategy)

Determine whether you can modify instances associated with an existing policy to address strategy actions, or if you must create a new policy or modify a policy model or execution settings.

Other Workflows

Persona: Various

Policies may use content that is produced in other workflows:

Queries to access data for analysis.
R Scripts for custom calculations.
Rules to implement custom actions.
Lookup or conversion tables created in APM (especially where a mathematical function defining the values to use is unavailable, for example, derived empirically; defined in regulations; looked up from manufacturer data such as a pump curve, etc.).

Design Policy

Persona: Solution Administrator (Policy)

Once the required policy logic is outlined and required inputs from other APM workflows are defined, design the policy by adding nodes and links to the policy design canvas and configuring them appropriately. Where a policy will take action such as creating a recommendation or sending an email alert, consideration should be given to whether the policy instance needs to be deactivated once the action is taken, to avoid duplicate requests and alerts.

Tip: The overall policy design should be outlined in advance, fully defining all calculations, queries, and look-ups that will be used, as well as decision criteria and actions to be taken in each case. For complex calculations, it may be helpful to prototype the policy using Excel or a similar program. To assist future users in understanding how the policy works, it is good practice to document the policy design in an "as-built" document, as well as assign descriptive names to policy nodes within the model itself.

Validate Ad Hoc

Persona: Solution Administrator (Policy)

Validate the policy using Ad Hoc inputs to verify that all of the required inputs to each node are configured and that the policy returns the correct values for a simple use case. After this is verified, proceed to verify that the policy handles more complex edge cases (for example, if a query used in the policy returns no rows, dividing by zero, etc).

To facilitate Ad Hoc validation, you can set up a policy instance and use the Copy to Ad Hoc feature to use instance values as a starting point. You can then edit the values as needed to test various scenarios. This approach is necessary in certain scenarios, as some nodes (for example, the AMS Asset input node) do not feature complete Ad Hoc validation capability. In these cases, you must use an Instance to access test records in the database (for example, example event records).

Tip: When creating complex policies, it is good practice to build and validate small sections of the policy design to check your progress, rather than attempting to build the entire policy in one step.

Define Execution Settings

Persona: Solution Administrator (Policy)

Configure the policy to be executed automatically (when a change occurs in a policy instance input that is set to trigger the policy) or according to a predefined schedule. It is also possible to set a policy to execute both automatically and on a schedule, but the use cases where this is required are rare.

Activate Policy

Persona: Solution Administrator (Policy)

Once the policy and its instances have been thoroughly validated, activate the policy so that the active policy instances associated with the policy will be executed according to the defined execution settings.

Add / Edit Instances

Persona: Analyst (Policy)

Add policy instance(s) to associate a set of existing, related records in the database with the policy.

Typically, each instance of a policy would represent a different asset on which the policy will operate. In some cases, a policy could have multiple instances per asset, where each instance is related to a different input data source (for example, Measurement Location or Health Indicator).

Validate Instances

Persona: Analyst (Policy)

Validate each instance to ensure that the correct records are specified and that the expected results are returned. If you are adding a large numbers of instances, at least a significant sample of them should be validated.

Activate Instances

Persona: Analyst (Policy)

Activate the instances that you want to be executed (according to the policy's defined execution settings).

In some policies, not all instances may be active at all times. For example, you may deactivate instances related to assets that are out of service or undergoing testing or maintenance. Or, an instance may be deactivated by a Deactivate This Instance node included in the policy design to prevent repeated alerts or recommendations being generated.

Note: Activating and deactivating policy instances can be done from Asset Health Manager as well as Policy Designer.

Execute Policy

Persona: Automated Process

The policy is executed according to the execution settings.

Go to the Execute Policy workflow.

Review Policy Execution History

Persona: Analyst (Policy)

Periodically review policy execution history to ensure that policies are functioning as expected. This review may reveal policy instances that need to be reactivated, edge cases that were not considered during policy design, policy execution settings that are inappropriate for the dynamics of the process being monitored, etc.

Note: When initially deploying a new policy, or significant batches of new policy instances, reviewing the initial policy execution results should be part of the final acceptance testing of the policy. Depending on customer requirements, the initial policy execution and review might be done in a test system prior to migrating the policy into a production environment.