---

name: mindtickle-common-errors description: 'Triage Mindtickle access, provisioning, content, assignment, reporting, and managed-integration failures using evidence and ownership boundaries. Use when an incident or rollout fails. Trigger with "triage Mindtickle failure".' argument-hint: "[incident-id] [symptom]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.8.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags: [saas, mindtickle, troubleshooting, incident-response, support] model: inherit effort: medium compatibility: Designed for Claude Code; production changes and vendor escalation require incident-owner approval

Evidence-First Mindtickle Failure Triage

Overview

Classify a failure by boundary, protect learner data, and produce the smallest reversible diagnosis before changing tenant state.

Prerequisites

• An incident owner, affected tenant, time window, population, and business impact
• The last known-good state and recent changes across identity, content, data, and integrations
• Approved access to redacted application and tenant evidence

Tool Discipline

Use Read, Glob, and Grep to inspect local logs and configuration, WebFetch for current official and authorized tenant guidance, and Write or Edit for a sanitized timeline and support packet.

Current Contract

Failures can cross customer identity providers, user sync, tenant roles, subscribed modules, managed connectors, customer adapters, and Mindtickle service boundaries. HTTP status alone does not prove root cause, and public material does not define universal error payloads.

Authentication

Use the least-privilege diagnostic principal. Redact tokens, cookies, personal data, assessment results, content URLs, and confidential tenant artifacts before sharing evidence.

Instructions

1. Freeze the symptom, first occurrence, blast radius, expected behavior, request or job identifiers, and recent changes.
2. Determine whether the failure is interactive access, provisioning, entitlement, content, assignment, reporting, connector, adapter, or platform availability.
3. Compare one failing case with one known-good case while changing only one variable at a time.
4. Validate tenant, principal, role, environment, contract digest, input identity, timestamps, and source-system state.
5. Check official service and support information, then distinguish customer-controlled remediation from vendor escalation.
6. Propose the smallest reversible repair with preview, approver, rollback, and post-change verification.
7. Reconcile the full affected set after repair; do not close on one successful sample.

Approval Boundaries

Do not reset identity settings, re-provision populations, republish content, edit scores, replay writes, or disable controls during diagnosis without the responsible owner.

Output

Return the timeline, impact, boundary classification, evidence table, ruled-out causes, proposed repair, approval requirement, verification, and support escalation packet.

Error Handling

Condition	Response
Evidence contains sensitive data	Stop distribution, redact it, and rotate any exposed credential.
Ownership boundary is unclear	Pause changes and assign customer and vendor owners in the incident record.
Platform incident is suspected	Preserve corroborating timestamps and use the contracted support channel and severity.

Example

incident=INC-1042; impact=27-users; boundary=user-sync; change=attribute-map-v4; repair=rollback-proposed; vendor-ticket=not-yet-needed

Resources

• Mindtickle Support Services
• Mindtickle Service Level Agreement

Next Steps

Attach the sanitized evidence to the incident and convert the root cause into a regression fixture.