A CRM-to-ERP webhook needs acceptance tests for failures and redelivery. The aim is to preserve accepted work, avoid duplicate orders, and prevent older data from overwriting newer state. Test the behavior of the complete workflow, including recovery after an interrupted attempt.

Separate event identity from business identity

An event ID identifies a change; a business ID identifies an order or customer. One order can have several legitimate changes. Verify the sender's identifier contract and scope deduplication keys by source and account. Do not suppress every update simply because it refers to an existing order.

Persist accepted work before acknowledging it

Verify signatures using the provider's documented method, preserving the raw request body where required. Enforce signature freshness where the protocol supports it. Reject requests with invalid signatures before business processing.

Persist the event key, payload, and pending status in one transaction with a database uniqueness constraint. This durable inbox can serve as the worker's queue. Return an acknowledgement, or HTTP 2xx ACK, only after the transaction commits. If persistence fails, do not report successful acceptance. An in-memory flag is insufficient.

Hypothetical acceptance cases

The identifiers and expected outcomes below are illustrative, not client results. Run these cases in a test environment.

1. Concurrent duplicates. Deliver E101 three times for order O42. Pass when there is one accepted job and one ERP order. Also send E102 for the same create-order operation on O42: there must still be one order.
2. Failure during acceptance. Make the queue transaction fail, then redeliver after connectivity returns. Also restart the worker after an ACK. Pass when accepted work survives and is processed.
3. Failure after the ERP saves. Stop the worker before it records completion. On recovery, reuse the same operation key supported by the ERP's idempotency mechanism, or a reference protected by ERP-enforced uniqueness. Reconcile the ERP record ID. If the outcome remains uncertain, assign it for investigation instead of blindly creating another order.
4. Out-of-order updates. Deliver version 8 of O42 before version 7. Pass when an atomic version check at write time prevents version 7 from overwriting version 8, while version 9 can still update it. If the source lacks reliable versions, retrieve current authoritative state or route the change for reconciliation.
5. Errors and forged requests. Simulate ERP 429 and 503 responses; send invalid data and invalid signatures. Retry transient failures with increasing delays, random jitter, and a retry limit; honor Retry-After when supplied. Route business-processing failures requiring intervention to a failed-work queue with an alert and an assigned owner.

Capture acceptance evidence

Record event IDs, business IDs, attempt counts, processing states, ERP IDs, and reconciliation results. Mask sensitive data. Test replay after correcting a failure. For document-based input, see our related guide to testing AI quotation extraction before ERP entry.

Frequently asked questions

Does HTTP 200 mean the ERP has been updated?

No. In this design, it confirms durable acceptance. Track processing separately to establish whether the ERP update completed.

Can this guarantee exactly-once processing?

There is no universal guarantee. Duplicate protection depends on the ERP mechanism, key retention periods, and replay rules.

To discuss an acceptance test scope, contact Viet Nis – IT On Cloud or call +84 888 728 730.

A successful backup job does not prove that staff can resume work. For a small or medium-sized business, a restore acceptance test should establish whether people can use the right content, with the right access, to complete a real task. Our 3-2-1 backup strategy guide covers backup placement. This checklist focuses on accepting the restored result.

Agree on scope and ownership

Choose one workflow, such as preparing a quotation from a price list and product documents. Assign an IT operator, a business owner who can approve the result, and a deputy. List the files, required versions, access rules, dependencies, and pass criteria before starting.

The recovery point objective, or RPO, sets the maximum acceptable data loss measured in time. The recovery time objective, or RTO, sets the maximum acceptable interruption before service is restored. These are business targets, not guarantees supplied by backup software.

Restore into an isolated environment

1. Prepare the destination. Use a separate test folder, virtual machine, or account. Prevent synchronization back to production, outgoing email, and writes to live systems. Never delete or overwrite original data to simulate a failure.
2. Run the restore. Select the agreed recovery point. Check the operator's permissions and access to decryption keys. Start timing at the simulated incident, including waiting periods and troubleshooting.
3. Validate the content. Open the files and confirm the required versions. Compare row counts, totals, or previously recorded integrity checksums where appropriate. Matching filenames alone are insufficient.
4. Test access. An authorized account must be able to read or edit according to its role. An account outside the permitted group must be denied access. Check ownership and sharing links as well.
5. Complete the workflow. Check formulas, linked files, applications, and database dependencies in the test environment. Stop the clock only when the business owner confirms that the sample task works.

Hypothetical test case: deciding whether it passes

Assume an incident at 10:00, an RPO of 30 minutes, and an RTO of 90 minutes. The selected backup contains data through 09:40. The team finishes the sample quotation at 11:05. The potential data-loss window is 20 minutes, and the measured recovery time is 65 minutes.

Both timing criteria pass in this scenario. However, the test still fails acceptance if the price list is the wrong version or an unauthorized account can access it. This is an illustrative example, not a client result.

Keep evidence that supports a repeatable test

Record the backup identifier, scope, timestamps, individual test results, approver, and defects requiring correction. Schedule another test after significant changes. A passing result applies to the scope and conditions tested; it does not establish recovery performance for every system.

Frequently asked questions

Is opening one restored file enough?

No. Confirm its version, access permissions, and whether it supports the workflow selected for the test.

What if the restored data is incomplete?

Mark the test as failed, preserve the originals and evidence, correct the configuration, and repeat the test.

To discuss suitable acceptance criteria, contact Viet Nis – IT On Cloud or call +84 888 728 730.

Reading a quotation PDF successfully is not the same as producing data that is safe to import into ERP. Before connecting an automated workflow, test critical fields, difficult documents and the cases that require human approval. The aim is to prevent a small extraction error from becoming an incorrect transaction.

Start with a test set and independently checked answers

Include quotations from different suppliers: text-based PDFs, scanned pages, multi-page tables and revised versions. Have a business reviewer establish the correct values from the originals before comparing the AI output. Do not use the model's own output as the answer key.

A small pilot could begin with 20 documents. That is a suggested starting point, not a sample size that proves performance across the whole business. Add missing document types before drawing broader conclusions.

Six failure cases worth testing

1. Wrong units: cases, boxes, individual items or labour hours. In a hypothetical example, VND 120,000 for a box of 12 must not silently become VND 120,000 per item. Apply conversions only through an approved business rule.
2. Wrong currency or number format: do not infer VND or USD from a supplier's location. Check currency labels, separators and a separate currency field.
3. Missing or shifted line items: test page breaks, repeated table headings and descriptions spanning several lines. Compare line counts with the original, not only the total.
4. Missing information: flag an empty field for review. Do not invent payment terms or quotation validity dates.
5. Wrong version or duplicate import: a quotation number can have a revised document. Retain document identifiers and decide how revisions are handled before creating transactions.
6. Failed reconciliation: compare quantities, unit prices, discounts and totals shown in the source. A business reviewer should resolve differences; the workflow should not change numbers merely to make them balance.

A high confidence score is not a business approval

Google Cloud's Document AI evaluation guidance distinguishes precision, recall and confidence thresholds. A confidence score is not a guarantee that a particular transaction is correct. Review results by field and by the impact of a potential error.

For fields that can change the supplier or payable amount, route early pilot results to an approval queue. Automate subsequent steps only after defining acceptance criteria, exception records and a way to stop invalid data from progressing.

Keep an audit trail that supports controlled retries

• The source document and extractor version.
• The extracted value, reviewer-confirmed value and reason for any change.
• Validation results, approver and target transaction identifier.
• Retry status so resubmitting a request does not create another transaction.

Frequently asked questions

Should AI connect directly to the live ERP at the start?

Begin with draft records or a test environment and a reviewer. A successful demonstration on a few documents is not evidence that every control can be removed.

Can the pilot use real quotations?

Use only data authorized for processing in an approved tool. Remove or mask information that is unnecessary for the test and restrict access to the sample set.

Planning a document-extraction pilot? Read the Google Drive handover checklist, explore Viet Nis services or request a consultation. Start with document types, expected volume and the destination system; do not send sensitive documents through a public form. Call +84 888 728 730.

A Google Drive offboarding checklist should identify business files, establish ownership and test the incoming employee's access before the departing account is retired. Shared drives help keep team documents under organizational control. Sharing a folder in My Drive does not turn it into a Shared drive.

Why a shared folder still needs a handover

Google's documentation explains that Shared drive files belong to the organization and remain when a member leaves. My Drive uses a different ownership model. Check where documents actually live, rather than relying on the list of people who can open them.

Consider a hypothetical sales team: an account manager keeps quotations in My Drive and shares a folder with colleagues. The sales director can see it, but that alone does not establish that the business has completed a durable handover.

Five steps before retiring an account

1. Inventory by business process. List quotations, agreements, trackers and project documents. Record the URL, owner, storage location and incoming custodian. Include forms, attachments and links that colleagues actively use.
2. Classify ownership. Separate organizational files, externally owned material and personal data. Customer-owned documents require an access arrangement with their owner; not everything visible to an employee can be transferred.
3. Choose a suitable handover method. Move team material to a Shared drive where the edition, permissions and file type allow it. Ask an administrator to assess ownership transfer or retention for exceptions. Test a small set before moving many files.
4. Test as the recipient. Open existing links and confirm the required read, edit or download actions. Test external collaborators separately. A permissions list is not proof that the real workflow still works.
5. Sign off and revoke access. Have the business owner accept the inventory. IT should handle the departing account, groups and sharing permissions through the offboarding procedure, recording unresolved exceptions.

Grant the access the role needs

Google distinguishes Manager, Content manager, Contributor, Commenter and Viewer. Use the Shared drive permissions table to match access to actual work. Someone who only reads documents does not need authority to manage members.

Keep a usable handover record

• Document URL and storage location after handover.
• Incoming custodian, required permissions and test result.
• Exceptions, including external files and broken links.
• Sign-off date and the person responsible for outstanding work.

Frequently asked questions

Is sharing a My Drive folder enough?

No. Access and ownership are different. Review each set of files and confirm that the recipient can perform the necessary work.

Do Shared drives replace backups?

Shared storage should not be the entire recovery plan. Define retention, backup and restore testing for important business data.

Where should a small business start?

Pilot the checklist with one department before the next staff change. Count broken links and documents without an incoming custodian to identify unfinished work.

Need help reviewing your company's Drive structure? Explore Google Workspace services from Viet Nis or request a consultation. Include your user count, current storage setup and handover date. Call +84 888 728 730.