We customized our lead approval workflow in AEC 2021 to include additional manager approval steps. After deploying the changes, our audit compliance reports show gaps - manager approval actions aren’t being logged properly.
The workflow executes correctly and leads progress through approval stages, but when we run audit reports for compliance reviews, manager-level approvals don’t appear in the audit trail. The initial sales rep actions and final approval are captured, but the intermediate manager review step is missing.
Here’s our custom workflow event handler:
public void onApprovalAction(WorkflowEvent event) {
Lead lead = event.getLead();
lead.setApprovalStatus("MANAGER_REVIEW");
LeadService.update(lead);
}
We need these audit logs for quarterly compliance reporting. Has anyone dealt with workflow audit event configuration issues where custom approval steps don’t generate proper audit entries? We’re particularly concerned about role-based audit permissions and whether our custom scripting approach is missing required audit triggers.
Thanks for the responses. I checked our role permissions and managers do have audit read/write access. The workflow definition XML does reference the custom handler, but I’m not seeing any explicit audit service calls in our code. Could you point me to documentation on the AuditLogService API? I’m also wondering if there’s a configuration setting to enable automatic audit logging for custom workflow events rather than manual API calls in every handler.
The root cause here involves all three areas you mentioned: workflow audit event configuration, role-based audit permissions, and custom scripting requirements.
Workflow Audit Event Configuration:
Your custom event handler isn’t configured to generate audit events. You need to modify your workflow definition XML to enable audit logging at the step level:
<workflowStep id="managerApproval" enableAuditLogging="true">
<auditEventType>LEAD_APPROVAL_ACTION</auditEventType>
</workflowStep>
Then update your event handler to explicitly log the audit entry:
public void onApprovalAction(WorkflowEvent event) {
Lead lead = event.getLead();
User approver = event.getCurrentUser();
AuditLogEntry entry = new AuditLogEntry();
entry.setEventType("LEAD_APPROVAL_ACTION");
entry.setEntityId(lead.getId());
entry.setUserId(approver.getId());
entry.setAction("MANAGER_REVIEW_APPROVED");
AuditLogService.log(entry);
lead.setApprovalStatus("MANAGER_REVIEW");
LeadService.update(lead);
}
Role-Based Audit Permissions:
Verify manager role has these specific permissions in Administration > Security > Role Management:
- AUDIT_LOG_CREATE (not just read/write)
- WORKFLOW_EVENT_AUDIT (specific to workflow operations)
- ENTITY_AUDIT_WRITE for Lead objects
Standard audit read/write permissions aren’t sufficient for workflow event logging. The WORKFLOW_EVENT_AUDIT permission is required for custom workflow steps to generate audit entries.
Custom Workflow Step Scripting:
Your current implementation is missing three critical components:
- User Context Preservation: Wrap your handler in SecurityContextHolder to maintain the actual approver’s identity:
SecurityContext context = SecurityContextHolder.getContext();
context.setAuthentication(event.getUserAuthentication());
-
Transaction Management: Audit logging must occur within the same transaction as the lead update to ensure atomicity. Use @Transactional annotation or explicit transaction management.
-
Audit Metadata: Include workflow-specific metadata in audit entries (workflow name, step name, transition path) for comprehensive compliance reporting.
For quarterly compliance reports, also configure audit log retention policies to ensure records persist beyond the default 90-day window. Set this in System Configuration > Audit Settings > Retention Period to at least 12 months for regulatory compliance.
After implementing these changes, test with a sample lead approval workflow and verify the audit entries appear in Administration > Audit Logs with the correct user attribution, timestamps, and action details. The compliance reports should then show complete audit trails for all approval steps including manager reviews.
Check the workflow step configuration properties. There’s an ‘enableAuditLogging’ attribute you can set at the step level in your workflow XML definition. Setting this to true should auto-generate audit entries for that step without code changes. However, if you need custom audit data fields, you’ll still need the manual API approach. The automatic logging captures basic who/when/what but not custom context like approval comments or business justifications.
We implemented a similar approval workflow and found that batch processing of workflow steps can also cause audit timing issues. If your workflow processes multiple leads in a batch operation, individual audit entries might get consolidated or lost. Consider implementing per-lead audit logging with transaction isolation to ensure each approval action generates a distinct, properly timestamped audit record with the correct user attribution.
I’ve seen similar audit gaps with custom workflow steps. The issue is usually that custom event handlers don’t automatically trigger audit logging - you need to explicitly call the audit service. Check if your workflow step has audit event registration configured in the workflow definition XML. Without proper event binding, the system won’t know to log those intermediate actions even though they execute successfully.
One thing to watch out for - if your custom workflow step runs under a system service account rather than the actual manager’s user context, the audit log will show the service account as the actor. This is a common issue with asynchronous workflow steps. You need to preserve the user context through the workflow execution chain, which requires setting up proper security context propagation in your event handler initialization code.