Skip to main content

Troubleshoot Automation Failures

Learn how to diagnose and resolve common automation issues.

Terence Cassidy avatar
Written by Terence Cassidy
Updated over a month ago

๐Ÿ—๏ธ Automation failures often result from LinkedIn limitations, incorrect configuration or expired session states. Reviewing error logs and activity details helps resolve issues efficiently.

โš ๏ธ Important: Support teams should avoid replaying failed steps unless instructed by development teams.

Identify Failures

  1. Open the automation and go to the Activity tab.

  2. Filter by Errors to see failed actions.

  3. Review the failure message to understand the cause.


Check the Admin Monitoring Panel

  1. Go to the Monitoring page in the Admin Panel.

  2. Search for the user or automation ID.

  3. Review the error count and descriptions to confirm recurring issues.


Common Failure Causes

  1. Connection requests containing messages on free LinkedIn accounts.

  2. Invalid or expired LinkedIn search URLs.

  3. Shared login warnings due to overlapping user and automation activity.

  4. LinkedIn rejecting actions due to reaching limits.

  5. Missing email integration for email-based steps.


When to Escalate

  1. If many errors appear without a clear cause in the error message.

  2. If failures persist after correcting configuration issues.

  3. If lead or activity data appears inconsistent across dashboards.

  4. If dev-level analysis is required to investigate API or platform issues.


๐Ÿ’ก Best Practices

  • Review automation settings before troubleshooting individual failures.

  • Ask the user whether they were logged into LinkedIn during automation run times.

  • Always verify LinkedIn search URLs before escalating issues.


๐Ÿค” FAQs


Q1: Should support retry failed activities manually?
Answer: No, failed actions should not be re-executed without developer confirmation.

Q2: How do I know if the issue is on LinkedInโ€™s side?
Answer: Repeated failures across multiple automations often indicate LinkedIn behaviour rather than configuration issues.

Did this answer your question?