PropertyIntel map metadata handoff checklist

How we work: This guide uses current public documentation and does not claim hands-on testing unless stated. Some links may later become affiliate links, at no added cost to you. Rankings are independent of commissions.

A PropertyIntel map is ready for a landscape crew when every approved map object can be traced to its property, project revision, catalog item, quantity, instructions, and current reference photos in the crew’s actual destination. Build the metadata fields first, freeze a revision, then test the field view, export, Aspire connection, or API path with synthetic records. A clean map on the estimator’s screen is not evidence that the handoff kept every value and relationship.

Download the PropertyIntel map metadata field dictionary and download the handoff acceptance test. The first file defines the controls to keep. The second provides 18 proposed tests for IDs, revisions, geometry, quantities, custom fields, photos, permissions, exports, API errors, and crew usability.

This is a desk-researched workflow, not a report of hands-on PropertyIntel testing. PropertyIntel’s current documentation and the independent landscape handoff guidance cited below were opened and checked on September 20, 2026. The downloads contain a test plan, not test results.

What changed in PropertyIntel Map Metadata?

PropertyIntel’s July 30, 2026 release added custom metadata to objects, lines, and shapes placed during takeoff. The current documentation names three field types:

• Text for free-form values;
• Single Select for one controlled option; and
• Multi Select for several controlled options.

Admins can define fields, group related fields, and assign them to master catalog items. An estimator placing that item is then prompted for the assigned metadata. The estimator can also add or adjust fields inside one project without changing the global template. PropertyIntel calls those project-scoped changes out separately in its release documentation.

Reference photos can be attached to selected items or materials on the map. This makes the feature useful for details that a measured area or material name does not carry: a condition note, a material specification, a zone label, or a visual reference for the exact mapped item.

Map Metadata belongs to the takeoff. PropertyIntel Reference Maps are a related but separate workflow built around property-level pins, groups, GPS location, photos, descriptions, read-only links, and reports. Do not treat “photo on a PropertyIntel map” as a sufficient identifier. The handoff manifest should say whether a photo belongs to a takeoff item or a Reference Map pin and should retain the source record ID.

What information should the handoff preserve?

The smallest dependable handoff has five linked layers.

Names still matter to the people doing the work, but names alone are weak joins. Two catalog items may have similar labels. A property can be renamed. The same area may exist on several project revisions. Preserve both the readable label and the source ID.

The field dictionary includes these joins and the operational fields around them. It is deliberately more specific than a generic project kickoff list. NALP’s handoff guidance calls for scaled designs, materials, labor summaries, equipment needs, photos or walkthrough videos, permits, client preferences, and participation from estimating, production, and field leadership. Map metadata should support that conversation; it does not replace scope, schedule, safety, procurement, or client communication.

Which custom fields belong in the catalog?

Use a master-catalog field when the same question should appear every time a particular service or material is mapped. Examples include:

• a zone label drawn from the company’s approved naming convention;
• a material specification that always needs estimator confirmation;
• an access or staging classification;
• a surface-condition selection that affects production planning; or
• a required photo category for a mapped item.

Group fields that belong to one repeatable decision. An irrigation-zone group, for example, might contain zone ID, controller reference, observed condition, and a photo requirement. A tree-care group might contain species or asset label, observed condition, access constraint, and escalation status. These are illustrative schemas, not built-in PropertyIntel field sets.

Use a project-only field when the question is genuinely exceptional. A temporary access restriction or a one-project client instruction should not quietly become an organization-wide catalog standard. Record the field’s scope in the handoff so production can tell a local exception from a reusable definition.

PropertyIntel documents an important lifecycle behavior: archiving a custom field removes it from associated catalog items, while values already entered on placed items in existing projects are preserved. That protects history, but it can also leave two revisions with different prompt behavior. Test an archived field against one existing project and one new project before changing a live catalog.

How should free text be limited?

Use selection fields when the downstream action depends on a controlled category. Reserve text for a concise factual note that cannot be represented honestly by an option list. Free text is poor at enforcing units, spelling, revision state, or responsibility.

A useful condition note states what was observed and where. It should not turn an estimator’s observation into an unsupported diagnosis. A useful material specification points to the approved material or says that approval is still pending. If the crew cannot act safely or correctly while a value is pending, the project is not ready for release.

Which handoff method should a landscaping team use?

Rank the methods by how closely the destination matches the work and how much evidence the team can preserve. The order below is a practical default, not a claim that every company has the same systems.

Do not combine these methods casually. A PDF, ShareView link, and API-created work record can drift into three competing versions. Name one released source, one destination of work, and one owner for exceptions. All other outputs should carry the same project ID and revision or be labeled as supporting material.

The software architecture for a five-crew landscape company uses the same source-of-truth rule across estimating, dispatch, time, and accounting. The map handoff applies it at object level.

How should the production revision be released?

Use a short controlled sequence:

1. The estimator completes geometry, quantities, catalog assignments, required metadata, and photo links.
2. A reviewer checks risky items against source documents, field evidence, and the approved estimate.
3. The approver freezes a named revision with project ID, revision, date-time, and approver.
4. The integration owner or estimator sends that revision through the chosen handoff method.
5. A production reviewer opens the destination under the real field role and runs the blocker checks.
6. The crew lead reviews scope, access, safety, materials, equipment, client expectations, and open questions before scheduling or mobilization.
7. Failed checks get one owner and remain open until corrected or formally accepted with a written limit.

The map object should connect to the estimate rather than replace it. The landscaping estimate template separates measured quantity, production assumption, unit cost, overhead, and markup. Keep those distinctions after handoff. A measured bed area and a note about existing mulch do not by themselves state removal depth, waste, crew hours, material order, or approved price.

How do you test IDs, quantities, and units?

Build a synthetic project that is easy to audit:

• one unique property and project;
• one area, one line, and one placed object;
• conspicuous but non-sensitive test names;
• different quantities and units for the three objects;
• one catalog-level field group;
• one project-only field;
• one text, single-select, and multi-select value;
• two visibly different test photos attached to adjacent objects; and
• one internal note plus one approved client-facing note.

Move that project through the proposed crew path. The reviewer should match each destination object to the source object without relying on screen position alone. Check the catalog item, geometry type, quantity, unit, each metadata value, each photo relationship, and the project revision.

Then edit one metadata value and one geometry value to create a second revision. The current crew destination should show the approved second revision, while the first is removed from normal access or clearly marked superseded. A link that always opens “latest” needs the same scrutiny as a named file: the crew must know what was approved and when.

The CRM migration acceptance workflow explains why count reconciliation is not enough. A project can have the right number of objects while their property, unit, note, or photo relationships are wrong.

How should permissions be tested?

PropertyIntel’s May 2026 release documents custom roles and controls for project creation, property management, and catalog editing. Its June release adds read-only project access and controls for templates, proposals, catalog prices, and PI Complete mappings. The release notes place these controls on enterprise tiers; confirm current contract and account availability rather than inferring access from a marketing page.

Test at least four roles:

Sign in as each actual test role. Do not demonstrate the handoff from an admin account and infer that a crew user sees the same controls. Also test one former user, one reassigned project, one hidden property, and one client link. The goal is sufficient access without exposing pricing, internal notes, employee data, or unrelated customer records.

The commercial site-audit workflow covers findings, corrective issues, enhancements, and client reports. This handoff has a narrower purpose: preserving takeoff object metadata and production context. Keep both workflows linked by IDs when an audit finding creates a new takeoff, but do not merge their statuses.

What should be checked in exports and ShareView?

PropertyIntel currently lists PDF, PNG, and XLSX for completed projects and a non-editable interactive ShareView link. Those format names do not establish that every Map Metadata value, object ID, reference photo, relationship, or revision marker is present.

Export the synthetic project in every format the team expects to use. Build a manifest that records:

• source project ID and approved revision;
• exported file name, format, time, and owner;
• included object IDs and catalog-item IDs;
• quantity and unit coverage;
• custom-field name, type, scope, and value coverage;
• included, linked, or omitted reference photos;
• internal and client-visible field behavior; and
• the controlled companion file required to fill any gap.

Open the outputs outside PropertyIntel under the same conditions the crew will have. A PNG may communicate location while carrying little structured data. An XLSX may preserve rows but lose the visual relationship the crew needs. A PDF may look complete while omitting the stable IDs needed for reconciliation. Choose a package based on demonstrated coverage, not file extension.

How should the PropertyIntel API be accepted?

As checked September 20, 2026, the PropertyIntel API is early access and available upon request for Enterprise+ organizations. The official configuration guide says it can retrieve and create projects, retrieve takeoff quantities, manage properties, catalog items, kits, users, and branches, and list, retrieve, or create Reference Maps with pin groups and pins.

Authentication uses OAuth 2.0 client credentials. The API introduction says access tokens expire after 24 hours. List endpoints accept pages with a documented maximum of 100 records, and rate-limited requests return status 429 with a Retry-After value. PropertyIntel also documents organization-scoped credentials, activity logs, immediate secret revocation, and 401, 404, 422, 429, and 500 error classes.

That is enough to design an integration trial, but not enough to declare the Map Metadata handoff complete. The opened API pages do not establish that takeoff-object custom fields and attached reference photos are returned with the exact identifiers and relationships required by the field dictionary.

Use nonproduction credentials and synthetic records. For every required field:

1. enter a conspicuous source value;
2. call the documented endpoint;
3. save the request, response, time, source ID, and destination ID;
4. verify the value, type, object relationship, and revision;
5. update the source once and observe the integration behavior;
6. force safe 401, 404, 422, and 429 paths;
7. confirm failures create visible exceptions rather than silent omissions or duplicate writes; and
8. revoke the test credential and prove it no longer works.

Do not place credentials, tokens, or customer data in the acceptance CSV. Store secrets in the approved credential system and put only the test evidence location in the sheet.

What makes the handoff acceptable to a crew?

The last test belongs to a crew lead who did not build the takeoff. Ask that reviewer to:

• open the correct property and approved revision;
• locate each synthetic object;
• explain its quantity, unit, required notes, and current photo;
• distinguish a standard catalog field from a project exception;
• identify information intentionally hidden from the field view;
• find the source estimate or approved scope; and
• name the person who owns a blocking exception.

The handoff passes when the reviewer can do this from the delivered system or package without estimator coaching. Correct data that cannot be found or interpreted by the intended role has not completed the handoff.

Keep the acceptance record with the project’s release evidence. When the catalog, role permissions, export, Aspire connection, or API changes, rerun the affected tests. PropertyIntel now provides a structured place for condition notes, material specifications, zone labels, reusable prompts, and reference photos. The operational value appears only when those details reach the correct map object, in the correct revision, through a path the crew has actually proved.