The Continuity module is a separate application and connects to the system through the API. With the installation of the module, an application is registered in the Authorized Applications section of the Administration module, named "Continuity Module". Anonymous access is granted to a user with administrative privileges, and the application is granted access to a number of features.
A number of other automatic registrations take place to allow the module to function, which should not be tampered with without the help of an experienced system administrator or the Support Team. These are listed below, along with explanations as to what each is used for.
Objects registered to manage business impact analysis
For every BIA initiated in the Continuity module, e-mail notifications are sent out according to the workflow rules used to send them. Keep in mind that the person who requested the revision is listed as the event author; the person responsible for the business component is assigned as event coordinator; and the current approver will be assigned as responsible and updated as the revision continues on to the next approver on the list. The title of each of these events is the name of the business component for which the business impact analysis was requested.
1) An event type is created, named "Continuity – Revision for BIA". Every time a business impact analysis is started, an event of this type is automatically created. These events allow notification e-mails to be automatically sent according to the workflow rules created, discussed further ahead. The person who requested the revision is listed as the event author; the person responsible for the business component is assigned as event coordinator; and the current approver will be assigned as responsible and updated as the revision continues on to the following approvers. The title of each of these events is the name of the business component for which the business impact analysis was requested.
Events of this type that are still open must not be edited at all. Closed and cancelled events can be deleted if necessary.
2) A List of Options attribute named "Revision Status" is created applied to Continuity – Revision for BIA events with the following options:
a. Revision Approved
b. Revision Cancelled
c. Revision Not Approved
d. Under Approval
e. Under Review
The Continuity module automatically updates the values of these attributes according to the status of the BIA, and the workflow rules use this status to know which e-mail notifications to send and to whom.
3) A Paragraph attribute named "Information" is created applied to Continuity – Revision for BIA events. This allows the comments provided on why business component data was rejected by the approver to be used as a variable (#event_attrib_Information#) in the notification e-mails sent through workflow rules.
4) Five workflow rules are created to send e-mail notifications, each of which is listed below. These workflow rules must not be disabled, or none of those involved in the BIA will receive e-mail notifications.
a. Continuity – Initiation of Business Component Revision
i. Description: Notifies those involved that a revision of a business component has been initiated.
ii. Object: Continuity – Revision for BIA
iii. Conditions: All conditions must be met. Field: Revision Status. Operator: contains. Value: Under Review.
iv. Execute Rule: When creating or editing an event and the rule has not yet been executed.
v. Actions: Sends an e-mail to the continuity manager who requested the revision and an e-mail to the person responsible for the business component, indicating that the revision was started.
b. Continuity – Revision of Business Component Data Cancelled
i. Description: Notifies those involved that a revision of a business component has been cancelled.
ii. Object: Continuity – Revision for BIA
iii. Conditions: All conditions must be met. Field: Revision Status. Operator: contains. Value: Revision Cancelled.
iv. Execute Rule: When creating or editing an event and the rule has not yet been executed.
v. Actions: Sends an e-mail to the continuity manager who requested the revision, an e-mail to the person responsible for the business component, and an e-mail to any approvers assigned indicating that the revision was cancelled.
c. Continuity – Business Component Data Approved
i. Description: Notifies approvers of the need to approve business component data that has been confirmed by the person responsible for it.
ii. Object: Continuity – Revision for BIA
iii. Conditions: All conditions must be met. Field: Revision Status. Operator: contains. Value: Under Approval.
iv. Execute Rule: When creating or editing an event.
v. Actions: Sends an e-mail to the designated approver according to the order in which the approvers were assigned, indicating that business component data was reviewed and confirmed by the person responsible for it and now requires their approval.
d. Continuity – Final Approval of Business Component Data
i. Description: Notifies those involved of the final approval of business component data.
ii. Object: Continuity – Revision for BIA
iii. Conditions: All conditions must be met. Field: Revision Status. Operator: contains. Value: Revision Approved.
iv. Execute Rule: When creating or editing an event and the rule has not yet been executed.
v. Actions: Sends an e-mail to the continuity manager who requested the revision and to the person responsible for the business component, indicating that the last approver on the list reviewed and approved the data and that the Impact Score was calculated.
e. Continuity – Business Component Data Not Approved
i. Description: Notifies those responsible that business component data was not approved.
ii. Object: Continuity – Revision for BIA
iii. Conditions: All conditions must be met. Field: Revision Status. Operator: contains. Value: Revision Not Approved.
iv. Execute Rule: When creating or editing an event and the rule has not yet been executed.
v. Actions: Sends an e-mail to the continuity manager who requested the revision and to the person responsible for the business component, indicating that the information on the business component was rejected by one of the approvers on the list.
Objects registered to manage the default workflow for testing plans
For every plan sent to the Workflow module for testing, approval, or activation, e-mail notifications are sent out according to the workflow rules used to send them. Keep in mind that the user selected for anonymous access for the Continuity module in the Authorized Applications section of the Administration module is listed as the event author; the person or group responsible for the plan is assigned by default as responsible for the event; the substitute responsible for the plan is assigned by default as event coordinator; and the author of the plan, the contingency and the substitute contingency staff, and the person or group assigned as responsible for the associated procedures will by default be assigned as involved in the event. Note that if no one is assigned as substitute responsible for the plan, the person or group responsible for the plan will be assigned as event coordinator.
1) An event type is created, named "Test Plan". When events of this type are created through the Continuity module, notification e-mails are automatically sent indicating that the plan attached to the event should be tested. These notifications are sent through workflow rules provided with the installation of the Continuity module.
2) A List of Options attribute named "Test Status" is created and applied to Test Plan events with the following options:
a. Approved
b. Not Approved
After a Test Plan event is created for a continuity plan, those who have received e-mail notifications can update the values of this attribute. The event will be automatically closed after one of the people assigned to the event changes the attribute status to either Approved or Not Approved.
3) A Paragraph attribute named "Comments" is created and applied to Test Plan events. This allows the comments provided on why a plan that has been tested was rejected by the testers to be used as a variable (#Comment_Test_Plan#) in the notification e-mails sent through workflow rules.
4) Three workflow rules are created to send e-mail notifications, each of which is listed below. These workflow rules must not be disabled, or none of those involved in the event will receive e-mail notifications.
a. Continuity – Test Plan – Event Created
i. Description: Sends an e-mail indicating that an event was created to test a continuity plan.
ii. Object: Test Plan
iii. Conditions: Test Status is blank
iv. Execute Rule: When creating an event.
v. Actions: Sends an e-mail to the people assigned to all the roles in the event, indicating that an event was created to test the associated continuity plan.
b. Continuity – Test Plan – Approved
i. Description: Sends an e-mail indicating that a continuity plan associated with an event was approved.
ii. Object: Test Plan
iii. Conditions: Test Status is equal to Approved
iv. Execute Rule: When creating or editing an event and the rule has not yet been executed.
v. Actions: Sends an e-mail to the people assigned to all the roles in the event, indicating that the plan was tested and approved. The event is also closed.
c. Continuity – Test Plan – Not Approved
i. Description: Sends an e-mail indicating that a continuity plan associated with an event was tested and not approved.
ii. Object: Test Plan
iii. Conditions: Test Status is equal to Not Approved
iv. Execute Rule: When creating or editing an event and the rule has not yet been executed.
v. Actions: Sends an e-mail to the people assigned to all the roles in the event, indicating that the plan was tested and not approved. The event is also closed.
Objects registered to manage the default workflow for approving plans
1) An event type is created, named "Plan Approval". When events of this type are created through the Continuity module, notification e-mails are automatically sent indicating that the plan attached to the event requires approval. These notifications are sent through workflow rules provided with the installation of the Continuity module.
2) A List of Options attribute named "Approval Status" is created and applied to Plan Approval events with the following options:
a. Approved
b. Not Approved
After a Plan Approval event is created for a continuity plan, approvers who have received e-mail notifications can update the values of this attribute. The event will be automatically closed after one of the people assigned to the event changes the attribute status to either Approved or Not Approved.
3) A Paragraph attribute named "Comments" is created and applied to Plan Approval events. This allows the comments provided on why a plan was rejected by the approver to be used as a variable (#Comment_Plan_Approval#) in the notification e-mails sent through workflow rules.
4) Three workflow rules are created to send e-mail notifications, each of which is listed below. These workflow rules must not be disabled, or none of those involved in the event will receive e-mail notifications.
c. Continuity – Plan Approval – Event Created
i. Description: Sends an e-mail indicating that an event was created to approve a continuity plan.
ii. Object: Plan Approval
iii. Conditions: Approval Status is blank
iv. Execute Rule: When creating an event.
v. Actions: Sends an e-mail to the people assigned to all the roles in the event, indicating that the plan was not approved. The event is also closed.
d. Continuity – Plan Approval – Approved
i. Description: Sends an e-mail indicating that a continuity plan associated with an event was approved.
ii. Object: Plan Approval
iii. Conditions: Approval Status is equal to Approved
iv. Execute Rule: When creating or editing an event and the rule has not yet been executed.
v. Actions: Sends an e-mail to the people assigned to all the roles in the event, indicating that the plan was approved. The event is also closed.
e. Continuity – Plan Approval – Not Approved
i. Description: Sends an e-mail indicating that a continuity plan associated with an event was reviewed and not approved.
ii. Object: Plan Approval
iii. Conditions: Approval Status is equal to Not Approved
iv. Execute Rule: When creating or editing an event and the rule has not yet been executed.
v. Actions: Sends an e-mail to the people assigned to all the roles in the event, indicating that the plan was not approved. The event is also closed.
Objects registered to manage the default workflow for plan activation
1) An event type is created, named "Plan Activation". When events of this type are created through the Continuity module, notification e-mails are automatically sent indicating that the plan attached to the event has been activated. These notifications are sent through workflow rules provided with the installation of the Continuity module.
2) A List of Options attribute named "Activation Status" is created and applied to Plan Activation events with the following options:
a. Activated
b. Cancelled
c. Finalized
After a Plan Activation event is created for a continuity plan, those who have received e-mail notifications can update the values of this attribute. The event will be automatically closed after one of the people assigned to the event changes the attribute status to either Cancelled or Finalized.
3) A Paragraph attribute named "Comments" is created and applied to Plan Activation events. This allows the comments provided on why a plan that was activated was finalized or cancelled to be used as a variable (#Comment_Plan_Activation#) in the notification e-mails sent through workflow rules.
4) Three workflow rules are created to send e-mail notifications, each of which is listed below. These workflow rules must not be disabled, or none of those involved in the event will receive e-mail notifications.
a. Continuity – Plan Activation – Event Created
i. Description: Sends an e-mail indicating that an event was created to activate a continuity plan.
ii. Object: Plan Activation
iii. Conditions: Activation Status is blank
iv. Execute Rule: When creating an event.
v. Actions: Changes the value of the Activation Status attribute to Activated, and sends an e-mail to the people assigned to all the roles in the event, indicating that the plan was activated.
b. Continuity – Plan Activation – Cancelled
i. Description: Sends an e-mail indicating that the activation of a continuity plan associated with an event was cancelled.
ii. Object: Plan Activation
iii. Conditions: Activation Status is equal to Cancelled
iv. Execute Rule: When creating or editing an event and the rule has not yet been executed.
v. Actions: Sends an e-mail to the people assigned to all the roles in the event, indicating that activation of the plan was cancelled. The event is also closed.
c. Continuity – Plan Activation – Finalized
i. Description: Sends an e-mail indicating that a continuity plan associated with an event was successfully executed.
ii. Object: Plan Activation
iii. Conditions: Activation Status is equal to Finalized
iv. Execute Rule: When creating or editing an event and the rule has not yet been executed.
v. Actions: Sends an e-mail to the people assigned to all the roles in the event, indicating that the plan was successfully executed. The event is also closed.