Signal Alerts - Common Errors and Recommendations
When working with Signal Flows, you may sometimes encounter “ThirdParty call failed,” Authorization, 401, 500, Validation, “Mandatory field,” or other errors when registrations process through your Flows.
This article reviews common errors you may encounter and subsequent steps you may need to take to ensure Signal Flows process registrations successfully.
Metrics > Troubleshooting
When reviewing the Metrics > Troubleshooting area, you will see totals labeled “IN RETRY QUEUE,” “TOTAL RETRIED,” “RETRIED ABANDONED,” and “VALIDATION ERRORS.”
You can get more detailed information on the Registration, Flow, and Error Messages by clicking on the total values.
- IN RETRY QUEUE - The total number of records passed through the Signal retry Queue in the selected timeframe.
- TOTAL RETRIED - Shows the latest results for records processing via the Retry Queue.
- RETRIED ABANDONED - Records that hit the max number of 3 retries were unsuccessful.
- NOTE - These records most likely indicate an issue with configuration or your Third-party systems.
- To have these processes go through Signal again, you replay them using a Custom Signal Replay Report from the Event.
Re-triggering Signal for selected records uses a Mass Action.
Error - “ThirdParty call failed”
These errors typically indicate that an error was generated by the system Signal attempts to integrate with.
The record typically includes additional information about the cause and the error itself.
The information included depends on the system Signal reaches out to through the Flow.
Below are examples and recommended next steps if you see these errors in Signal.
- Unauthorized
- Unauthorized indicates that the information sent by Signal for Authorization is incorrect.
- If you are getting this for all registrations processing through a Flow, check the Flow’s Connection and confirm the credentials/endpoints are still valid.
- If other registrations from other events process through the same Flow, check the Mapping in your Flow to identify any fields used for authorization.
- Check the corresponding field if you are getting the errors.
- Upstream request timeout
- Upstream request timeout normally indicates an issue with the system Signal reaches out to in the Flow.
- If the third party has a “Status” page, check for recent problems that could cause the errors.
- If you consistently get this error, review the Flow’s Connection setup to ensure the Endpoints used are correct.
- If the third party has a problem and it persists for some time, records may become “Abandoned” once the records are retired and fail three times.
- Use a Signal “Replay” report to re-trigger the Flows for individual registrations.
- Access token is expired. / The supplied refresh token has been destroyed.
- Records that throw this error typically process correctly the next time the system runs them through the Retry queue.
- If you see a large number of these errors, check your Flow Destinations to confirm their information is correct.
- Check with your Third-party system to confirm the third party is not encountering issues.
- Meeting ########### is not found or has expired. / Event has been expired
- These errors are normally from Flows that work with webinars (Zoom, ON24, Bluejeans, etc.).
- These errors indicate the Meeting/Webinar that the system attempts to integrate with has already ended.
- Review the Meeting/Webinar and confirm the Meeting/Webinar matches your Event.
- Confirm the Meeting/Webinar has the correct Date/Time.
- If you get this error and the Meeting/Webinar has not already passed, reach out to Certain Support.
- The user is already registered.
- This error is seen in many webinar systems (GoToWebinar, Zoom, etc.).
- This error indicates that a registration already exists in the Webinar for the email address sent over.
- Registration has not been enabled for this meeting
- This error is for Zoom Webinars/Meetings.
- This error indicates that the Webinar is not set up in Zoom to allow Registration.
- To fix this, edit the Zoom Meeting and check the option next to Registration as “Required.”
- Value too long for field / STRING_TOO_LONG / ValidationException
- These errors indicate that values sent by Signal are being rejected because they fail the Third-Party System’s validation settings.
- Check the Fields Mapped in the Flow Destinations and check those fields in your Third Party System.
- Example: Eloqua Form Fields are created with a default character limit of 35.
- The character limit can be changed by editing the form field within Eloqua.
- Service Unavailable
- Service Unavailable indicates there is an issue with the Third-party system or a problem with the internet.
- The issue or problem prevents information from moving back and forth between Signal and the third party.
- If you only see one or two of these errors, check with the Third-party system to confirm the third party is experiencing issues.
- If the problem occurs for a long time, records may process through the Retry Queue 3 times and become “Abandoned.”
- If records become “Abandoned,” replay the Signal triggers for those records once the Third-party system is back to normal.
- This replay can be done by creating a “Replay” report in the Event and processing a Mass action to re-trigger the Signal Flows for selected records.
Miscellaneous Error Messages
Below is a list of other error messages you may see and recommendations on steps to take.
- Mandatory fields missing [List of Fields]
- Mandatory fields missing indicates that fields from Signal are blank.
- Signal will not send the information to the Third-party for that record.
- If you update the Registration with the required values soon after the error is received, the information should send when the record is run through the Retry queue.
- If your Event is not collecting these fields for registrations, update the Event to collect the required fields.
- If updating the Event is not an option, edit the Flow Destinations.
- Edit the Flow Destinations by updating the Mapping so the fields are not required.
- Read timed out
- Read timed out indicates that Signal did not receive a response to the request made via your Flow to the Destination/Third-party.
- Signal times out requests after 1 minute.
- If you receive a large number of these errors, reach out to your Third-party system.
- Confirm whether the third party is experiencing issues or can optimize processes to get a response back to Signal requests in a shorter timeframe.
- Error getting auth headers
- Error getting auth headers is a general authorization error.
- This error normally clears up when the record is processed via Signal’s Replay Queue.
- If you see a large number of these errors, review the Connection that your Flow uses.
- Review the Flow’s Destination endpoints.
- Entity FAILED after MAX attempts... “[Connection Name” is not tested yet
- This error occurs if testing has not been completed for a connection.
- Within Connection Setup, a user needs to click “Save & Test” and successfully complete the subsequent authentication.
> Note: As most errors received depend on the Third-party that Signal is sending data to, you may see different errors than the ones listed above. > Signal attempts to isolate pertinent information from the response received and pass it along via the Metrics area. > If you encounter errors that do not look to relate to the Third-party system that your Flow integrates with or if you are unable to understand the errors, please reach out to our Support team at Help@certain.com. > In the email to Support, include the error received, the Flow triggered, and one or two of the Registration Codes for the records that received the error.