Review and decision control

Get the right event layout approved—and keep the record

Move from scattered screenshot feedback to named milestones, resolvable comments, a frozen approval candidate, and a decision tied to the exact version that was reviewed.

Frozen decision candidateComments and named milestonesApproval tied to a version
A venue representative and event hosts reviewing a floor plan before approval
Current event layoutWORKING
Editable first passHuman review required
1Frozen decision candidate2Comments and named milestones3Approval tied to a version
The job to be done

Make “approved” refer to something specific

A useful decision record identifies the plan, the version, the requester, the responder, and what happens when the layout changes afterward.

Review the same revision

Requesting approval freezes the current canvas and settings as a version with a checksum, rather than asking someone to approve a moving target.

Keep changes visible

Comments can be opened, resolved, and reopened. Named milestones preserve context before a significant edit or client review.

Return edited work to review

A content change moves the floor plan back to working status and cancels a pending request, preventing the old decision from silently following new work.

How it works

A floor-plan decision loop your team can explain

Approval is a product state with a traceable version—not a safety certificate and not a substitute for every specialist review.

1

Prepare the candidate

Finish the intended revision, save the plan, address obvious open questions, and name a milestone if the team needs a recognizable checkpoint.

2

Request a decision

Add the approval context. Margo freezes the current scene as the candidate and records the requester, time, version, and scene checksum.

3

Approve or request changes

An owner or admin can record an approved or changes-requested response with a note. The decision stays attached to that version.

4

Release or revise

Share or print the current reviewed plan. If the event changes, edit the working plan and send the new version through review rather than reusing the prior status.

What the workflow supports

Version control for a spatial decision

The review record sits beside the editable plan, so the layout and the conversation about it do not drift into separate files.

Immutable milestones

Each saved milestone keeps its own canvas, settings, name, note, creator, and timestamp. Restoring a milestone creates a new version rather than rewriting history.

Resolvable comments

Workspace members can add plan comments, mark them resolved, and reopen them when the issue returns.

Role-gated response

Only workspace owners and admins can approve or request changes, keeping the decision action separate from ordinary editing.

Planning checklist

Define the approval before you request it

Teams use the word approval for different things. State the scope so the record is useful and does not imply authority the reviewer does not have.

  • Which event, room, plan name, and version are being reviewed?
  • Is the decision about client preference, venue operations, production, or another scope?
  • Which dimensions, counts, vendor footprints, and assumptions have been verified?
  • Which comments remain open, and who owns each unresolved decision?
  • Who is authorized to respond inside the workspace?
  • What must trigger a new review, and who receives the released plan?

Questions to settle before the room is set

What exactly is frozen when approval is requested?

Margo stores the current canvas and plan settings as a version and calculates a scene checksum. The request points to that version, so the decision can be matched to the reviewed scene.

Who can approve a plan?

Within the product, workspace owners and admins can respond to a pending request. Your organization still decides whether that person has authority for the stated review scope.

What happens if someone edits the plan afterward?

A content change returns the plan to working status. A pending request is canceled, and a previously approved version remains in the history rather than being relabeled as the new work.

Can external clients approve from the shared link?

The current shared link is view-only. It does not expose an external approval control, so a workspace owner or admin must record the decision in Margo.

Put one real revision through a controlled review

Create the candidate, name the decision scope, resolve the important comments, and confirm how the plan returns to review when it changes.

See the approval workflow →