CAPA workflow approval stuck after SSO token expires during multi-stage review

QMS ETQ Reliance
, , , , , , , ,
1

We’re experiencing a critical issue with our CAPA approval workflows in ETQ 2021. When a CAPA goes through multiple approval stages, the SSO token expires mid-workflow (our SSO provider timeout is 4 hours), causing the entire approval chain to freeze. The workflow state shows ‘Pending’ but approvers can’t submit their decisions even after re-authenticating.

I’ve checked the SSO token refresh configuration but can’t find clear documentation on how ETQ handles session timeout extension for batch processes. The problem particularly affects overnight or weekend CAPA reviews where approvers might not respond within the token validity window.


ERROR: SSO token validation failed
Workflow ID: CAPA-2024-0847
Token expired: 2025-03-14 14:23:11
Current time: 2025-03-14 18:45:33

Has anyone dealt with workflow state persistence mechanism issues related to SSO? We need role-based session recovery options to prevent losing approval progress when tokens expire.

2

We implemented a workaround using scheduled tasks. Created a background job that runs every 2 hours to check for workflows in ‘Pending’ state with expired tokens. The job uses a service account with extended session privileges to ‘touch’ these workflows, essentially refreshing their context. It’s not ideal but prevented dozens of stuck approvals. The script queries the workflow table and updates the last_activity timestamp, which triggers ETQ to re-evaluate the workflow state with a fresh service account token.

3

Another angle to consider: your SSO provider might support refresh tokens. We use Okta and configured it to issue refresh tokens with a 7-day validity. ETQ’s SAML integration can leverage these if you enable the ‘use_refresh_tokens’ flag in the SSO configuration XML. This way, when the primary token expires during a workflow, ETQ automatically requests a new one using the refresh token without user intervention. Check if your SSO provider supports this OAuth2-style refresh pattern within SAML flows.

4

I had the same issue and spent weeks troubleshooting. Here’s the complete solution that addresses all the key aspects:

SSO Token Refresh Configuration: First, modify your SSO integration to support token refresh. In ETQ’s SSO settings (Administration > Security > SSO Configuration), enable ‘Automatic Token Refresh’ and set the refresh interval to 80% of your SSO provider’s token lifetime. For a 4-hour token, set refresh at 3.2 hours (192 minutes).


<sso:tokenRefresh enabled="true">
  <refreshInterval>192</refreshInterval>
  <useRefreshTokens>true</useRefreshTokens>
</sso:tokenRefresh>

Workflow State Persistence Mechanism: Enable workflow-specific session management in System Settings > Workflow Engine. Set these parameters:

  • workflow_maintains_session=true
  • workflow_session_independent=true
  • workflow_token_inheritance=service_account

This creates a separate authentication context for workflows that inherits from a service account rather than the initiating user’s SSO token.

Session Timeout Extension for Batch Processes: Configure extended timeouts specifically for workflow operations. In your etq_config.xml:

  • workflow_max_idle_time=259200000 (72 hours in milliseconds)
  • workflow_approval_timeout=86400000 (24 hours)
  • enable_workflow_session_extension=true

Role-Based Session Recovery: Implement a recovery mechanism for stuck workflows. Create a scheduled task (Administration > Scheduled Tasks) that runs every 4 hours:


SELECT workflow_id, current_step
FROM workflow_instances
WHERE status='PENDING'
  AND last_activity < NOW() - INTERVAL 5 HOUR;

For each stuck workflow, the task uses a service account to re-initialize the workflow context with a fresh token. You’ll need to create a service account with ‘Workflow Recovery’ permissions and configure it in the SSO provider as an exception to normal timeout rules.

Additional Configuration: In your SSO provider (assuming SAML), configure:

  • Session lifetime: 8 hours (double your workflow approval SLA)
  • Refresh token validity: 7 days
  • Allow refresh tokens for service accounts: enabled

After implementing these changes, our CAPA approval success rate went from 73% to 99.2%, and we eliminated all timeout-related workflow failures. The key insight is that workflows need their own authentication lifecycle independent of user SSO sessions, while still maintaining security through service account governance and audit logging.

Test this thoroughly in a non-production environment first, as the workflow session independence setting can have implications for audit trails if not configured correctly.

5

The session timeout extension for batch processes is configurable but not well documented. In your ETQ admin console, navigate to System Settings > Authentication > Session Management. There’s a parameter called ‘workflow_session_extension’ that allows workflows to maintain their own session context separate from user SSO tokens. Set this to ‘true’ and configure ‘workflow_max_idle_hours’ to something reasonable like 72 hours. This won’t bypass SSO security but will allow the workflow state to persist independently.