A corporate gift approval evidence repository must answer a narrow question: which authorized person approved which version, under which policy, before execution? Confluence, Google Drive and SharePoint can support parts of that record, but their objects, approval settings and export behavior differ. Start with the system your team can govern, then test whether a second operator can retrieve the approved decision without receiving unnecessary recipient information.
Define the decision record before comparing tools
A folder named “approved” is not enough. It may contain a revised quotation, an old budget and a screenshot of a conversation without identifying which combination was authorized. A useful record joins the decision, its exact object, the approver’s authority and any conditions. A dispatcher should not have to infer approval from the newest attachment or from somebody having edited a page.
Separate three records. The policy record defines who can authorize a gift and which exceptions need escalation. The decision record states what those people actually authorized. The execution record shows what was ordered or shipped against that authorization. A repository stores and connects these records; it does not determine whether a gift is lawful, appropriate, taxable or permitted by the recipient’s employer. Those decisions remain with the responsible policy, legal, privacy, finance and business owners.
Use a small manifest rather than copying every working document into one unrestricted folder. Include a stable decision identifier, campaign identifier, source object identifier, approved version reference, decision timestamp with time zone, approver identity and role, policy version, authorized scope, conditions, amendment references and retention owner. Record an exported snapshot’s filename and checksum when useful. A checksum can help detect changed bytes; it does not prove who approved them or establish that the person had authority.
Keep recipient addresses and contact details in the separately authorized fulfillment system. The approval manifest can refer to a restricted recipient-list version and record a count without exposing the list. For the wider sequence of request, decision and dispatch ownership, use the corporate gifting operations hub. The repository choice should serve that sequence, not introduce a competing approval chain.
Assign ownership before choosing features. The business owner prepares the request, the designated approver decides within a recorded authority limit, the records owner maintains the evidence package and the operator retrieves the released version. One person may perform multiple roles in a small team, but a self-approved exception should never become invisible merely because the software permits editing.
Compare the same evidence problem in each repository
The comparison below is a fit assessment, not a ranking or a tenant test. Product documentation was checked on October 20, 2026. Account editions, administrator settings, object types and organizational policies can change the result. No price, integration or universal retention guarantee is assumed. The rows use alphabetical product order for readability.
| Repository | Evidence object to identify | Configuration to verify | Failure to test |
| --- | --- | --- | --- |
| Confluence | Published page version, approval cycle and linked attachments | Eligible plan, enabled page approvals, space access and page restrictions | A later page or attachment obscures the approved combination |
| Google Drive | Native document revision or uploaded binary version, plus decision evidence | Account eligibility, approval reset settings, reviewer access and version preservation | An uploaded file is treated like a native document, or an edit leaves ambiguous approval |
| SharePoint | Library item and selected version, approval status and decision manifest | Versioning, draft visibility, content approval and actual permissions | The reviewer opens a current draft instead of the authorized version |
Comparison method: apply the same identity, version, access, amendment and export questions to each candidate. Treat an untested feature as unknown, not a failed score. Existing identity administration, staff familiarity and the cost of maintaining a second evidence location belong in the decision. A new tool is justified only when a documented requirement cannot be met safely in the current system.
For a team already working in a controlled document library, moving approvals into a separate knowledge space may create duplicate ownership without improving retrieval. For a policy team that maintains context in pages, a short decision page may be easier to read than a folder tree, provided the approved attachments remain identifiable. Neither advantage resolves missing authority or a weak retention policy.
Read the approval and version settings literally
Confluence Cloud now documents page approvals for Premium and Enterprise plans. Its approval guidance describes requesting and responding to approvals on pages, not live docs or blog posts, with edit permission required for those actions. Space administrators control availability and relevant settings. The activity log can show approval cycles, participants, times and comments. Do not describe this as a feature every Confluence account has, or as automatic authorization for a particular gift.
Page history also needs interpretation. The page editing documentation explains that updates create versions and that restoring an older version creates a new version. It also explains that deleting a version permanently removes it and renumbers later versions. Therefore a version number by itself is not an eternal evidence identifier. Record the page identity, relevant decision context and an appropriately controlled snapshot; restrict destructive history actions under your organization’s records policy.
Access controls need an equally precise reading. Confluence’s page restriction documentation distinguishes inherited viewing restrictions from editing restrictions: a parent page’s edit restriction does not automatically restrict editing on its children. Test the actual decision page and attachment path using the intended reviewer account. Do not assume a parent label proves that every descendant is protected.
Google Drive distinguishes uploaded binaries from native documents. Its version management guidance says older uploaded-file versions may be removed after 30 days or 100 newer versions unless preserved with “Keep forever.” Native document history follows a different model. The native document history instructions require edit permission to inspect earlier versions. Granting a reviewer editing rights merely to see history may conflict with least privilege; a controlled approved snapshot can be the safer review object.
Drive’s approval documentation also makes account eligibility and settings important. When the option requiring all reviewers to approve the same content is enabled, edits reset approvals; when it is disabled, edits do not reset them in the same way. The published eligibility statement must be checked against your actual account. A locked document should not be described as immutable archival evidence. Record the configured behavior, not the behavior somebody remembers from another account.
For SharePoint, use documentation applicable to the deployed product rather than an older server-only article. The modern versioning configuration guide covers settings such as major and minor versions, content approval, draft visibility and version limits. Inspect the selected library’s settings with its administrator. A restored version becomes a new version; restoration is a new event to document, not permission to erase the history of the decision.
Run a small-team retrieval case before migrating
Consider a hypothetical 25-person company already using Google Drive for a 40-recipient customer campaign. These are illustrative inputs, not a customer story or a tested tenant. The marketing owner proposes a product specification, quantity, budget and dispatch date. Finance is the named budget approver; the policy owner handles recipient eligibility and exceptions. The records coordinator creates decision GIFT-040 with links to the request, the applicable policy and the restricted recipient-list version.
Suppose the planning assumption is a merchandise allowance of $40 per recipient: 40 multiplied by $40 gives $1,600 before any separately estimated tax, freight or service fees. This is arithmetic for the example, not a supplier quotation. The decision manifest must say whether the approved ceiling includes those other costs. Otherwise a later freight estimate can make “within budget” mean two different things to finance and dispatch.
The coordinator identifies whether the quotation is a native document or an uploaded PDF. For the PDF, the coordinator preserves the selected binary version under the organization’s retention rules and records a controlled snapshot identity. For a native document, the coordinator records the selected revision and creates the review artifact the authorized reader can actually access. Merely renaming either file “final-approved” is not an acceptance step.
Finance records the approval with identity, role, time zone, ceiling and conditions. The coordinator binds that decision to the exact specification and quotation version. A separate operator, who did not prepare the package, receives only the approval record and appropriate read access. The operator must locate the authorized product, quantity, budget interpretation and dispatch conditions without opening recipient addresses. Record the evidence path and any missing permission in the pilot sheet.
Now introduce a controlled amendment: the supplier offers a different finish after approval. Do not overwrite the approved quotation and keep the old decision looking current. Create an amendment linked to GIFT-040, identify the new specification and ask the responsible approver whether the existing authority covers it. Hold dispatch until the released manifest clearly distinguishes the original approval from the changed version.
The pilot passes only when the second operator retrieves both the original decision and its amendment, identifies which version is released, and cannot access the address list without separate authorization. If the operator sees only the newest file, or needs broad editing access to interpret history, the team repairs the evidence package and repeats that test. A successful upload is not a successful retrieval exercise.
Keeping Drive may be the proportionate choice for this team if the controls pass. Moving the same incomplete manifest into another repository would add migration work while preserving the defect. Conversely, if required access separation or version preservation cannot be demonstrated with the actual account and policy, escalate that specific gap instead of declaring the entire product unsuitable.
Test a cross-team enterprise decision without broadening access
Consider a second hypothetical case: a 1,200-person organization uses SharePoint for controlled files and Confluence for team procedures. Procurement owns the quotation and approved specification; a business approver owns the campaign purpose; finance owns the budget decision. An independent reviewer needs evidence of both decisions, not unrestricted access to every campaign file. This is a proposed test design, not a report of installed integrations or a real customer deployment.
Choose one authoritative decision location. One workable design is a restricted library containing the manifest and approved file versions, with a procedure page linking to that record. Another is a controlled decision page referencing governed library objects. The records owner must explain which object governs dispatch and who maintains the links. Do not let both locations claim to contain the sole final version.
Create a disposable test package with fictional recipients and no production personal data. The administrator assigns two approvers and one reviewer according to the intended access model. A separate nonmember account tests the negative case. Test the actual folder, page, attachments and exported package; access to a parent location is not a substitute for checking the object people will open.
Run a full cycle: submit a version, capture both authorized decisions, export the intended evidence package and ask the reviewer to retrieve it. Then revoke one test approver’s access through the authorized administrator, revise the test request and attempt the permitted restoration of a test version. Never delete real approval history to demonstrate a feature. Record who performed the administrative change and whether the historical decision remains attributable after access changes.
The acceptance condition is not that a former approver can still log in. It is that the preserved record identifies the person and their authority at decision time while current access follows the new policy. If the export loses identity or time information, add a controlled decision manifest or change the export process. If the manifest points to a mutable “latest” file, replace that ambiguity with a specific released version reference before further testing.
The reviewer then verifies that the revised request did not silently inherit the old business approval. A content-approval flag and a campaign authorization can serve different purposes. Document how a substantive product, quantity or budget change triggers a new decision, and who may decide that a clerical correction does not. Unrecorded discretion is a weak amendment policy, even when the interface displays a green status.
Finally, the records owner confirms retention and deletion responsibility with the appropriate legal and privacy owners. The reviewer should retrieve sufficient evidence without exporting the recipient database. For practical separation of consent, regional access and retention responsibilities, use the gifting data governance guide. A repository comparison cannot replace those organizational decisions.
Use the downloadable pilot without manufacturing a winner
Download the English approval evidence repository workbook. Version: October 18, 2026, v3; source check: October 20, 2026. It contains three sheets: Start Here + Criteria, Retrieval pilot, and Source and version log. The workbook is an English-language working template, not a populated product ranking, legal checklist or certification of your environment.
Begin with one campaign and one existing repository. On the criteria sheet, assign an owner to each requirement and document the reason for any nonnegotiable control. On the retrieval sheet, test six scenarios for each repository actually under consideration: authorized access, denied access, approved-version retrieval, amendment, controlled deletion/restoration, and export completeness. Leave other repositories untested rather than inventing observations to fill the grid.
The observed-result input accepts numeric 0 or 1. A blank means not tested; zero means failed. A recorded success also requires an evidence reference, owner and valid spreadsheet date. Enter a whole date without a time; the owner must still verify that the test occurred and the entered date is accurate. Text, out-of-range numbers and missing evidence produce distinct statuses. The formula’s “Recorded” status describes a documented observation, not a business approval or a recommendation. The records owner must still assess whether the observation satisfies the requirement.
Why an export is not the same as native history
A PDF can preserve what a page looked like while omitting approval cycles, comments, attachment versions or access history. A native document revision, an uploaded binary version and an exported snapshot are three different objects. List each required object in the manifest, then open the exported package with the intended reviewer account. Confluence’s export guidance describes available export options; it does not make every format a complete approval archive. Keep the original controlled references when your policy requires them.
For a repeatable pilot, follow this sequence:
-
The policy owner defines the decision and required authority before files are assembled.
-
The records owner identifies the exact test objects and saves the current configuration evidence.
-
The administrator grants only the intended test access and records the approved test scope.
-
The approvers make the fictional decision; the second operator retrieves the released package.
-
The reviewer checks both positive and negative access, amendment and export outcomes.
-
The business owner accepts the operational design only after unresolved failures have an owner and a retest result.
Give the pilot a bounded scope. Use fictional names, one quotation, one specification and one amendment so the reviewer can distinguish a control failure from a confusing test dataset. Before changing access, the administrator records the intended participants and confirms that the test will not affect shared production groups. After the test, remove temporary access and retain only the authorized evidence. The purpose is to evaluate the design, not to collect more recipient information.
Document exceptions in plain language. If the reviewer can read the approved specification but cannot see the decision timestamp, the result is incomplete even though the file opens. If the export contains the timestamp but not the decision maker, it still fails the attribution requirement. A repair might be a separately controlled decision record, a narrower permission arrangement or a different export package. Choose the repair that addresses the observed gap, then repeat the same test with the same acceptance condition.
Keep procurement convenience separate from evidence quality. A supplier-facing folder may need quotations and artwork but should not automatically contain internal policy exceptions or all recipient details. Conversely, the internal reviewer may need the decision rationale without access to supplier commercial negotiations. Write down these audiences before granting access; one broad link shared with everyone makes the pilot easier to complete but defeats the access question it was meant to test.
At handover, the outgoing coordinator gives the next operator the manifest, the released-object reference, the unresolved-issue list and the responsible owners. The next operator demonstrates retrieval rather than simply acknowledging receipt. If the team cannot repeat that handover after the original preparer steps away, keep the design in trial and repair the missing dependency. This is a practical acceptance threshold, not an assurance that every future audit or legal request will have the same scope.
Update the source/version log when a product setting, account edition, contract or policy changes. Schedule the next documentation review for January 18, 2027, or earlier after a relevant change. These dates describe this template’s review method, not a guarantee that vendor features will remain unchanged. Preserve previous pilot results so a later improvement does not erase the reason an earlier design was rejected.
Choose the smallest defensible evidence system
Choose the repository that can preserve an attributable decision, an identifiable approved object and appropriately limited retrieval in your actual environment. Keep the current system when it passes those tests with clear ownership. Introduce another system only for a specific unmet requirement, with migration and link maintenance included in the decision. The best-looking approval interface is not a substitute for a retrievable amendment history.
Start with the two worked cases as test patterns, not ready-made architectures. A small campaign needs a released manifest more than a sprawling folder taxonomy. A larger organization needs a single authoritative record and verified cross-team access more than another copy of the quotation. In both cases, stop execution when the approved version or responsible decision maker is ambiguous.
After an authorized decision is clear, Giftpack can help coordinate the agreed sourcing, production and fulfillment work within the contracted scope, while the team returns appropriate execution evidence to its chosen repository. That is an adjacent operational role, not a replacement for document governance, employer gift policy, legal review, privacy decisions or the organization’s approval authority.