Workflow Automation QA: Four Checks After the Save Succeeds

An automation dashboard can say “success” while the customer sees nothing. A database row may have been saved while the public page is still showing an older version. The article may open while its cover image is not yet available. A page can look complete and still send the inquiry button to the wrong destination.

That is why, in the scheduled workflows I run for Botonglee, a successful save is not the definition of done. The workflow is complete only after the result has been checked in the same place and form in which a customer will encounter it.

Separating execution from verification in a scheduled workflow

1. Read the current state before writing

A scheduled task may run more than once on the same day. The computer may have restarted. A run may have stopped halfway through. A recovery task may start because the final report never arrived, even though the external action succeeded.

If the recovery immediately creates a new result, it can publish the same article twice or send the same notice twice. The first action should be a read, not a write.

Does today's result already exist?

Is its saved state a draft or published?

Do the internal record and the public page agree?

Is there another result with a different title but the same subject?

Exact title matching is too weak for duplicate protection. Punctuation changes, words move, and translated editions use different sentences. Compare the subject carried by both the title and summary, and deliberately link results that belong together, such as Korean and English editions of the same article.

This step is not merely defensive. It tells the automation where to resume. If the record already exists but the public page does not, the next action is verification or repair—not another insertion.

2. Verify dependencies before making the main result public

Order matters when text, images, files, and deployment travel through separate systems. If an article is published before its cover image is available, early visitors see a broken page even though every individual upload eventually succeeds.

My sequence is deliberately plain:

Public-use approval: confirm that the image or file may be published.

Web preparation: create the required format and dimensions.

Address check: open the public asset address and confirm that it responds.

Publication: release the article only after those checks pass.

The same principle applies outside publishing. An email with an attachment is not ready when the message body is finished. A product page with a download is not ready when the product record exists. A video release is not ready when the video arrives but the captions do not.

Treat each dependency as a visible precondition. “The file should be there soon” is not a pass. Either the customer-facing address works or the workflow waits.

3. Leave the admin screen and open the customer view

A database row and a working customer experience are different outcomes. After publishing, close the management view and open the live URL.

I check four things:

The page address opens normally.

The title and body language match the address.

The cover and inline images render.

Inquiry buttons and internal links lead to the intended destinations.

Bilingual publishing adds another layer. An English article may exist in the database but return a missing page when opened through the Korean route. The two editions also need an explicit relationship so the site can present the correct language alternative.

The live page is also where editorial residue becomes obvious. Internal notes, temporary image instructions, placeholder labels, and formatting tokens can survive a clean-looking save. They are easy to overlook in structured data and hard to miss when reading the article as a visitor.

Do not limit the check to the top of the page. Follow at least one action link. Open the cover image directly. Scan the ending, where inquiry links often live. The final conversion path matters as much as the article body.

4. Resume from the failed stage instead of repeating everything

When the final check finds a problem, rerunning the entire workflow may create a larger one. If publication succeeded and only the completion report failed, starting from the beginning can produce a duplicate post.

Recovery becomes safer when the workflow records stages:

Save failed: retry the save.

Image is not public yet: wait and check the same image address again.

Public page is delayed: keep the existing record and recheck its URL.

Link is wrong: correct the source and the published result, then inspect the live page again.

Every recovery run begins by reading the current state. Not repeating completed work is more important than making the rerun look fast.

A useful completion record says what was actually observed. “Publication request sent” describes an attempt. “Public page opened, image rendered, and inquiry link reached the expected page” describes an outcome.

A ten-minute automation QA sheet

Add these five lines to the end of any scheduled workflow:

Before execution: read whether the same result already exists.

Before publication: verify that assets, files, and destination links are ready.

After publication: open the real customer URL and inspect text, images, and buttons.

After a failure: record the last successful stage and resume from the next one.

In the report: describe the verified result, not merely the request that was sent.

Automation is not complete when it presses the button for you. It becomes operational work only when it also confirms that the intended result arrived.

If you are deciding what a workflow should automate and where a person still needs to look, begin by writing down the current sequence and the conditions that must never be guessed. You can also read What I Turned Off: The Automations That Survived and the Ones That Did Not for the judgment rules I use before keeping an automation alive.

If you want help mapping a repetitive workflow and its verification points, send the current process through the Botonglee contact page.