Testing and execution history

Open any integration from Settings > Integrations and you get three things on one page: a health panel at the top, the editor in the middle with a test console beside it, and every recent run listed at the bottom.

Anyone who can edit integrations can see all of this. Running a test needs the execute permission for integrations on your brand, and if you don’t have it the console says so and tells you what to ask for.

Testing

The test console sits to the right of the editor and stays there as you move between tabs. A new integration has to be saved before it can be tested, because a test run calls the saved configuration.

Sample inputs gives you a box for each input parameter, filled with its default where it has one. Below that you see the request as it will actually go out, with the variables filled in, which catches a mistyped path before you send anything.

Press Run Test. The result appears underneath: the outcome, the HTTP status the other service returned, how long it took, the error if there was one, and the Raw Response.

A test is a real request to the real endpoint and it’s recorded like any other run. If the integration books something or charges something, test it against the other service’s sandbox.

Once you have a response, the Transform tab can use it. Its tree shows the reply you just got, and clicking a node sets the transform expression or turns the node into an output parameter.

The health panel

Three boxes across the top of the page.

Last 24 hours counts how many runs completed and how many failed. It says there’s been no activity when nothing has run.

Last failure is when the most recent one was, or that none have been recorded.

The third box, Paused after failures, says whether the integration is taking runs right now. No means it is. Yes means it’s paused, with the number of seconds until it starts accepting runs again, and next to it a Resume now button that lets it start again immediately. Only a Tenant Admin sees that button.

The execution log

The list at the bottom of the page holds the 25 most recent runs, newest first.

Column	What it shows
Date	When the run started
Status	How it ended
Duration	How long it took
Method	The HTTP method used
HTTP Status	The code the other service returned

Click a row to expand it. You get the Request URL as it was actually sent, the time it started, the Input Data it was given, the Response Headers and Response Body that came back, the Transformed Output after your expression ran, the error message if it failed, and the Response Shape, which is a summary of the reply’s structure.

Any credential the request used shows as [REDACTED] in what’s kept, and headers that commonly carry one are replaced the same way.

What the statuses mean

Status	Meaning
PENDING	Queued, or for an async run, sent and waiting for the callback
RUNNING	The request is in flight
COMPLETED	Finished, and the result was stored
FAILED	The request errored, or something in the configuration was wrong
EXPIRED	An async run whose callback never arrived in time

When something goes wrong

WorkWing tries again on its own when a failure is the sort that might clear: the other service returning a server error, or not answering. It gives up straight away on anything a retry can’t fix, such as a request the other service rejected, a destination that isn’t allowed, or a mistake in your variables or your transform. Max retry attempts on the General tab sets how many tries a retriable failure gets.

If an integration keeps failing, WorkWing stops calling it for a short while so a broken endpoint doesn’t produce an endless run of failures. Anyone who runs it during that time sees a message saying the integration is temporarily paused, and how long until it will be tried again. It starts working again by itself, and a Tenant Admin can press Resume now in the health panel to start it again straight away.

Your Tenant Admins also get an email when an integration fails. Repeats of the same failure are grouped, so one broken endpoint doesn’t fill anyone’s inbox.

Working out what happened

The status is FAILED. Start with the HTTP status in the log. A 401 or 403 means the credential, so check the run’s Request URL went where you meant and then check the credential at the other end. A 4xx of any other kind usually means the request body or a parameter. Expand the row and read the error, which often carries the other service’s own explanation.

The status is EXPIRED. For an async run, the other service never posted its result back. Check their logs. Check that your body template actually includes {{callback_url}} and that they’re posting to it. The wait before a run expires is the Timeout (minutes) on the General tab.

The status is PENDING and stays there. Same causes as expired; it will become EXPIRED when the timeout is reached.

The result isn’t what you expected. Expand the run and compare Response Body with Transformed Output. If the body has what you want and the transformed output doesn’t, the transform expression is the problem. If the transformed output looks right but the form field is empty, the output parameter’s path is the problem.

The run failed saying the shape changed. You have Strict response shape on and the other service has altered its API. Compare the Response Shape on this run with an earlier one and update your output paths.

A variable was rejected. Personal details can’t go in a URL or a header, only in the body template. See template variables.

Clearing the cache

If the integration caches its answers and you need a fresh one, open the Caching tab and press Clear Cache. Everything stored for this integration is dropped, and the next run goes out to the other service.

What’s next

• Custom integrations: fix an authentication failure
• Integration blocks: what your engineers see when a run fails