Amend an accepted delivery request
Change an accepted delivery’s destination, timing or handling resources and explain the change to its requester.
Use Change (the pencil button) to adjust the delivery arrangements of an accepted request. You must be signed in as a manager assigned to its project, or as an administrator. This amendment process keeps the request accepted; it does not send it back through an open-request approval step.
Before changing, read the request summary and check the project calendar. Decide which arrangement needs to change and what explanation the requester needs.
Save an amendment
- Open the project’s Requests list and choose accepted or all in Status.
- Find the request and use Show to open its summary page (Summary - Request #). Confirm its identity, current arrangements and messages. For an accepted request the summary page shows the buttons Change and Refuse at the top.
- Select the pencil button labelled Change, either in the request’s row of the list or at the top of the summary page. The button is offered for accepted requests only, and only if you may update them. The dialog is headed Edit request.
- Adjust the destination, date/time or assigned resources as needed. Use the fields available for this project and request. Start time and End time are lists in 15-minute steps for the whole day; as a manager you are not limited to opening hours. End times at or before the Start time are greyed out, and a later Start time clears an End time that is no longer possible (Choose time). Choose a new End time then.
- Add a Message to requester (marked (optional)) when instructions or an explanation are needed. A message can be useful even when the delivery fields stay the same.
- Read the conflict feedback. The Conflict warning lists the requests and events that overlap your new arrangements, for example “Request ID # 18: 22.01.2030 13:00 - 15:00” or “Event ID # 3: title”, with the Conflicting items. It says that you can resolve the conflicts later and does not stop you from saving. If a conflict message field is offered, distinguish its audience from the message to this request’s requester.
- Select Save. Select Close instead to leave the dialog without submitting the amendment.
- You return to the page where you opened the dialog (the list or the summary page). Check the saved request’s status, time, destination and resources. A changed submission reports Request was successfully amended. A submission with no changed details and no added messages returns without that success notice. On the summary page, changed values are highlighted and the previous value is shown crossed out, for example the Delivery time slot.
What the amendment form covers
| Field group | Available changes |
|---|---|
| Destination | Building, Floor and Sector, or the conditional Area option. Recheck dependent choices after changing their parent. |
| Delivery window | Date, Start time and End time (15-minute lists; End time must be after Start time); Duration when enabled and shown. |
| Handling resources | Assigned 'drop off area', Assigned 'drop off tool' and the own-tools option, labelled Own offload tools where shown. |
| Requester communication | Message to requester. |
| Conflict communication | A separate message for requesters of conflicting accepted requests where offered. |
Delivery Info is displayed for reference when present. This dialog does not provide general editing of company contacts, vehicle dimensions or the original delivery description.
Understand the result
Changing original selections can show a warning that the requester will be informed about changes. That wording does not prove actual email delivery.
A real delivery change, a requester message, or an applicable conflict message can create an amendment history entry. Submitting unchanged details with no messages is treated as no change. A requester message alone can therefore produce a meaningful saved amendment without moving the delivery.
Changed delivery details or a requester message schedule amendment notification mail. Conflict notifications concern requestors of conflicting accepted requests. The path can schedule mail even without a conflict message: it goes to the request email, copies request subscribers and project watchers, and BCCs active administrators. A blank conflict message creates no in-app request message through that path. Notification scheduling does not guarantee email delivery. Manager changes to significant delivery details can also produce the Request was amended marker shown in the list and summary; a message-only amendment need not create that marker.
Amendment emails can show Changes with old → new values for fields that can be compared reliably. Some changes may not be listed. Full request details remain below; the HTML version can also show previous values next to amended values. An email may describe an earlier amendment: open the request page to check its latest state. A manager message appears only when it is nonblank.
Handle problems
Only accepted requests qualify. If the request is now open or refused, check its current state and use the appropriate decision process rather than repeatedly saving the old dialog.
If End time is empty or not later than Start time (the arrival), nothing is saved. The dialog stays open. A red summary at the top, for example Please check 1 entry, lists each problem as a link to its field (for example End time: Please fill in), and the message also appears under End time. The check compares the clock times on site. Choose a later End time and select Save again.
Other validation errors also leave the form available for correction. Read the displayed error, recheck required destination and time fields, and inspect available resources for the selected date. A successful amendment does not establish that every overlap has been removed: the request can still carry a conflict tag in the list. Resolve the actual arrangements using scheduling conflicts. If the delivery must be cancelled entirely, use Refuse.
Check the current selection before saving
In Accept and Change, the compact check status describes the date, time and resources currently selected in the dialog:
| Check status | What to do |
|---|---|
| Checking this selection… | Wait for the current selection to be checked. |
| Conflicts remain for this selection | Inspect the overlapping Accepted requests, Open requests and Events, their links and conflicting items. |
| No conflicts found for this selection | No overlaps were detected by this check for the selected time and resources. This check does not save the selection. |
| Complete the date, time and required selections to check conflicts. | Complete the date, time and required destination selections; End time must be later than Start time. Select an unloading tool or Own offload tools, and enter a numeric Duration when shown. The form automatically checks the updated selection. |
| The conflict check is unavailable. Please try again. | The check failed; this is not a clear result. Select the Check again link. |
When conflicts remain, the short hint links to the existing time controls. It can additionally link to an affected unloading area, unloading tool, building, floor or sector when those controls are present. Change the selection using the indicated controls, then let it be checked again. The hint disappears when the check finds no conflicts. It does not find a free slot or choose an alternative for you; all existing fields stay directly editable.
The notice Changes are not saved yet. remains separate from the conflict result. Select Accept or Save to submit the decision, then check the actual success message and saved request. A successful acceptance or amendment can still retain overlaps; inspect its saved conflict result and coordinate the arrangements when needed. Managers may deliberately retain a coordinated overlap. A clear draft does not confirm that anything has been saved, and a successful save does not prove that the schedule is conflict-free.
The existing Message to requester and separate message to requesters of conflicting accepted requests keep their different audiences. See conflict communication before sending either message.
If saving reports Saving could not be confirmed. Check the request before trying again., the dialog stays open with your entered values. A failed response or network interruption does not establish whether the server saved the decision. Select Close, then reload or reopen the request to get its current status and details before submitting again; the page behind the dialog may still show the earlier state. Do not immediately repeat the decision. This save warning is separate from a failed conflict check. A response with validation errors can display a new form without this warning. Its disappearance does not tell you whether the earlier decision was saved; still reload or reopen the request before submitting again.
A successful acceptance, or a changed amendment, also includes the saved conflict result after its success sentence: Conflicts remain for this booking. or No conflicts found when saving. Read that suffix as well as the success sentence. An amendment with no changed details and no added messages returns without a success notice.
Element availability
When you change the delivery date or arrival time, all assigned elements must be available at that new arrival; newly assigned elements must also be available. Existing unavailable selections remain visible for correction. An unchanged historical allocation can remain during a message-only change. In Elements, changing an element does not cancel the request, reassign its elements or send an email notification about the request; coordinate the needed amendment explicitly.
Amend an accepted request
These images show the English RERA interface, captured on 13 November 2026 UTC in a synthetic local project. Example project dates use a synthetic January 2030 clock. The GIF presents selected actual steps. Options depend on the project and your role.
