Request Actions
Copying, following, holding, reopening, and deleting work requests.
Beyond responding and resolving, a work request's action menu offers a handful of operations worth knowing. Each is permission-gated by your user type, so your menu may show a subset of these.
Copy
Copy opens the new-request form pre-filled from an existing request — fields and custom fields included — so a recurring one-off ("same leak, other wing") doesn't have to be retyped. The copy is a fresh request: it isn't linked to the original, and the requesting user is cleared for you to set.
Follow
If your organization allows following, a Follow action (a star on the request) adds you as a follower — you'll get notifications about the request and can read and respond to it even if it isn't yours or assigned to you. Following is how a head custodian keeps an eye on a request another campus submitted. Some user types can also add other people as followers to pull them in. Unfollow turns it off.
Place Hold and Remove Hold
Place Hold pauses a request — the request keeps its place in the lifecycle but is marked On Hold, as described in Work Request Statuses. Placing a hold can adjust the due date, and if your organization has added custom fields to the hold form (a "Hold reason" drop-down is a common one), you'll fill those in too. Remove Hold resumes the request and notifies the people involved.
Reopen
A finalized request that turns out not to be fixed doesn't need a duplicate: Reopen puts it back into the working lifecycle — to Pending Resolution if it still has someone assigned, otherwise to Pending Assignment — with a fresh due date, and notifies the people involved. The full history, responses, and costs stay attached, which keeps the equipment's story in one place.
Delete and Undelete
Delete removes a request from normal view but doesn't destroy it — deletion in FMX is soft. Users with the right permissions can filter for deleted requests and Undelete them, history intact. There's no way to permanently purge a request from the web app, which is the point: an audit trail survives an accidental (or convenient) deletion.
A worked example
A librarian follows up on a squeaky door repair from last month — it's squeaking again. The technician finds the finalized request, chooses Reopen, and it lands back in his queue with the original photos and his earlier responses intact. Seeing the same hinge fail twice, he copies the request's details into a new request for replacing the hinge entirely, and the librarian selects Follow on it to get notified when the part comes in.