Detecting a product alert, shipping hazardous material to an uncertified customer, or discovering that a supplier contract has expired should have consequences in the ERP. How do you connect what is happening in the business with what the system allows people to do?
Imagine a distributor receives a complaint about a possible product defect. Quality opens an incident and sends an email: “Do not sell until we complete the review.”
An hour later, Sales prepares another order for that product. They have not read the message. The warehouse keeps working. In Business Central, nothing has changed.
The company has identified the problem and someone has issued an instruction. But the operation continues.
The question is simple: if we know something should not be done, why does the system still allow it?
The gap between warning and control
In many companies, control decisions travel through email, meetings, or internal messages: do not buy from that supplier, do not send that document, do not use that product.
Compliance depends on everyone involved receiving the warning, understanding it, and remembering it at exactly the moment they are about to act. It also depends on whoever takes over during a colleague’s absence knowing the situation.
A warning communicates a risk. A preventive control acts on the operation before that risk materializes.
That is the role of Entity Rules in AWH GRC: applying restrictions to Business Central records at defined points in a process and releasing them when the expected conditions have been met.
The entity is the record being acted upon—for example, a product, supplier, or document. The rule connects its situation with the actions that need to be restricted.
What AWH GRC adds to the block
Business Central already provides blocking mechanisms. For example, it can block products for certain operations. The value of AWH GRC is connecting those restrictions to the process that justifies them: what happened, who needs to intervene, which checks are still outstanding, and when the record should be released.
Back to our distributor. The control flow is specific:
- The incident is recorded and linked to the affected product.
- The process reaches a stage that applies the intended restriction.
- Quality investigates and gathers the evidence.
- The responsible person decides whether the operation can be authorized again.
Opening an incident is no longer just a way to record what happened: it can change what people are allowed to do.
The following scenarios illustrate controls that can be designed with this approach. Their scope depends on the entities, actions, and connections configured in each implementation; an external alert or an expiry must feed the process for the intended response to take place.
Situations where a rule changes the outcome
1. A quality alert while the product is still for sale
A recurring complaint, an unfavorable test result, or a manufacturer alert may justify stopping sales of a product while it is investigated.
The objective is to restrict the affected operations as soon as the process is opened, without waiting for every salesperson to check their email. Release remains linked to the Quality decision and the required evidence.
Scope matters: an incident affecting a specific batch should not necessarily stop every related item. The control should be applied at the level supported by the implementation and appropriate to the actual risk.
2. A supplier whose certificate has just expired
Purchasing approved a supplier months ago. Today, a certificate required to continue doing business with that supplier expires, but the supplier record is still available for new orders.
A validity-review process can place the supplier in a restricted state until the renewed documentation has been received and validated.
The exit condition deserves as much attention as the block itself: receiving a file does not mean that it has been verified as valid. It should be checked that it belongs to the supplier, covers the required activity, and has the appropriate validity period.
3. A document awaiting approval that already looks final
An order with exceptional conditions is awaiting authorization. Meanwhile, someone changes its contents, prints a copy, or sends it by email.
The approval process loses its purpose if the document can be used as final before the decision is made, or if what is executed no longer matches what was reviewed.
Rules can be designed to restrict editing, printing, and posting during the relevant stages. The design must also account for corrections: if the document is returned for changes, it must go through the appropriate validations again.
That way, approval applies to a specific set of conditions, not simply to a document number.
4. A disputed invoice that reaches the payment proposal
The person responsible for a service reports that the work is incomplete. The invoice has already been posted, and Treasury prepares payments without knowing about the dispute.
Business Central allows vendor ledger entries to be marked as on hold so they can be excluded from the automatic payment proposal. That functionality has a specific documented scope in Microsoft’s documentation.
The control process can coordinate that hold with the resolution of the dispute: who confirms the service, what amount is accepted, and what evidence allows the process to continue. If other payment routes also need to be prevented, they must be covered by the design.
The objective is to prevent the Treasury schedule from getting ahead of the decision on the invoice.
5. A product requiring an authorization that the customer or supplier does not have
Some products are subject to regulations that determine who can buy or sell them: hazardous substances, materials with specific transport requirements, or components requiring an authorization. The requirement does not depend on the product alone, but on the combination of the product, the regulation, and the other party in the transaction.
A salesperson may prepare an order for a new customer without knowing that the item requires accreditation the customer has not provided. The same applies to Purchasing when a supplier does not have the certificate required to supply the product.
The approach is to link each regulatory requirement to the affected products, suppliers, and customers, and check whether the required certificate or authorization exists before allowing the operation. While it is missing, the operation remains restricted; once the documentation is validated, the process releases it.
This means regulatory compliance no longer depends on someone remembering the requirement at exactly the moment an order is created or delivered.
Blocking is only half of the control
A block without an owner eventually becomes an emergency. Repeated emergencies tend to create workarounds.
That is why every restriction should have a clear answer to four questions:
- What triggers it? An incident, an expiry, a rejection, or a pending review.
- What does it prevent? The specific actions that expose the company to the risk.
- Who resolves it? The person or department responsible for reviewing the case.
- What allows it to be removed? The evidence and decision required to continue.
Concurrent reasons must also be considered. A supplier may have pending documentation and, at the same time, an open quality incident. Resolving the first issue should not remove a restriction that is still required because of the second.
If an urgent exception exists, it should be part of the procedure: defined authorization, reason, and scope. “Unlock it and we’ll review it later” moves the decision outside the control that was meant to govern it.
Three questions to review your operations
Think about the last time someone said, “This cannot go ahead”:
- Did the decision change anything in Business Central, or did it remain a message?
- If someone encountered the block, could they tell why it had been applied, who was responsible, and when and how it would be resolved?
- Was it clear who could authorize the operation to continue and what evidence was required?
Task-managed Entity Rules connect those decisions with ERP operations. They allow the process to have consequences while it is open and ensure that returning to normal operation follows a controlled decision.
Because detecting a problem is of little use if, one minute later, the company can keep operating as if nothing had happened.
What operation should stop in your business when an incident occurs? That can be the starting point for an AWH GRC demonstration based on a real case from your business.
