Business Continuity Plan for TDX based Key Management Process

1. Purpose

This Business Continuity Plan (BCP) defines how the Key Issuance/Return and key cutting process will continue operating during a TeamDynamix (TDX) service degradation or outage. The plan ensures that essential services remain available, critical actions are captured, and data is reconciled once full service is restored.

2. Scope

This plan applies when:

  • TDX is slow or intermittently responsive,

  • TDX exhibits performance degradation,

  • TDX is unavailable (planned or unplanned), or

  • TDX automations (iPaaS, workflows, web services) are failing or timing out due to platform issues.

Includes:

  • Key Checkout Requests (Service and Form Location)
  • Key Return Requests (Service and Form Location)
  • Key Cutting Requests (Service and Form Location)

  • All dependent workflows, forms, custom attributes, automations, approvals, tickets, and integrations.

Excludes:

  • Non-TDX systems (unless integrated).

3. Criticality

Key Request Processes are classified as:

  • High-Criticality / Medium-Criticality / Low-Criticality

  • Required RTO (Recovery Time Objective): <X hours>

  • Required RPO (Recovery Point Objective): <X hours>

4. Dependencies

This process depends on the following TDX components:

TDX Components

  • Ticketing (Requests)

  • KB Articles

  • Workflows (Approvals, Tasks)

  • iPaaS Integrations 

  • Forms and Custom Attributes

  • Asset/CI Management

  • Reporting 

External Dependencies

  • Authentication (SSO/AzureAD)

  • Email notifications (SMTP/TDX Notification Engine)

  • API connections to external systems

5. Continuity Response Plan

5.1 Trigger Conditions

Activate the continuity plan if any of the following occur:

  • TDX response times exceed 60 seconds.

  • Users report inability to submit or update tickets.

  • iPaaS flows fail more than 4 times within 8 hours.

  • Scheduled workflows queue without executing for more than 20 mins.

  • TDX Status Page or UITS monitoring confirms a degradation/outage.

5.2 Immediate Actions (First 15 Minutes)

  1. Verify the Issue

    • Check TDX Health Dashboard or status.uark.edu

    • Attempt simple TDX actions (search, ticket update)

    • Review iPaaS execution logs for error patterns

  2. Notify Key Stakeholders

    Technology Solutions (TS) Team (Stuart Bailey, Kristy Hodge, Acey Hagar, Darla Kay Sanders Weatherford)

    • (Technology Solutions will contact and coordinate with appropriate groups in University IT Services.)

      • Director of Business Applications (Owner of TDX Platform)

      • UITS Incident Management (They will handle communications)

      • TDX Admins (to work with vendor for a resolution)

    • FAMA Stakeholders

    • Contact current key requestors to delay picking up keys until performance issues is resolved. 

  3. Initiate Work-Logging Continuity Mode

    • Move to Manual Intake & Tracking until TDX stabilizes.

5.3 Manual Intake & Tracking Procedures

If TDX forms cannot be submitted

Use an alternate intake method:

Option A – Microsoft Forms fallback

  • Prebuilt mirrored form for Key Processes in TDX Sandbox. 

  • Submissions write to a SharePoint List or Excel file

  • Timestamp, requester, details, attachments captured

  • Auto-messaging to requester using Power Automate

Option B – Locally stored intake spreadsheet

  • Spreadsheet stored on Teams/SharePoint

  • Columns mirror TDX fields (“minimum viable fields”)

Option C – Shared mailbox fallback

  • Requests sent to service@uark.edu

  • TS triage team logs items in the spreadsheet

5.4 Operational Continuity

If TDX Workflows Cannot Run

  • Move approvals to email-based approval:

    • Approver replies “Approved” / “Denied”

    • TS stores decisions in the continuity tracker

    • Workflow resumes in TDX once service returns

If iPaaS automations fail

  • Disable automated retries to avoid loops

  • Manually queue actions:

    • KB updates

    • CI edits

    • Report ingestion

    • Ticket attribute sync

  • Use PowerShell/Python local scripts if available to capture input for later reprocessing.

If TDX Reporting fails

  • Pull static copies from:

    • Power BI dataset refreshes

    • Local report exports

    • Cached HTML/CSV files

6. Recovery Plan (After TDX Is Restored)

6.1 Confirm System Stability

  • Test ticket creation, updates, workflow processing

  • Run a simple iPaaS flow to validate API responsiveness

6.2 Resume Automated Systems

  • Re-enable iPaaS flows

  • Re-activate scheduled workflows

  • Confirm notifications are sending normally

6.3 Reconcile Offline Work

Using the continuity tracker:

  1. For each offline item:

    • Create or update the corresponding TDX ticket

    • Attach the offline record

    • Replay the workflow steps as needed

    • Note “Created via BCP after outage”

  2. For automations:

    • Run catch-up scripts (if applicable)

    • Update CIs, KBs, or service offerings as needed

  3. Confirm all approvals have been re-entered.

7. Communication Plan

During Outage

  • Help Desk issues standard message:

    • “TDX is experiencing performance issues. Your request is still being captured and will be entered as soon as TDX is restored.”

Stakeholder Updates

  • Initial alert at detection

  • Status update every <X> hours

  • Post-incident summary within one business day

8. Roles and Responsibilities

Business Owner

  • Approves BCP activation

  • Provides decision-making for escalations

  • Validates manual steps

Technology Solutions

  • Executes continuity procedures

  • Manages manual intake

  • Handles backlog reconciliation

EADS

  • Supports automation failures

  • Validates data integrity post-outage

Service Desk

  • Communicates with end users

  • Redirects callers to fallback intake methods

9. Documentation & Storage

  • This BCP is stored in:

    • Teams → Technology Solutions → Governance

    • Knowledge Base → Internal / Administrative

  • Manual intake templates stored in:

    • SharePoint: TS Business Continuity Folder

    • Local fallback directory: \uits-share\TS\BCP

10. Review Cycle

This plan will be:

  • Tested annually

  • Updated quarterly or after major service changes

  • Reviewed after any real incident impacting <Process Name>

Print Article