Explainer · Trust and security
How Pole handles sensitive changes
A practical view of the account context, record checks, history, and follow-up around a sensitive change.
- Category
- Trust and security
- Best for
- Security, governance, and product reviewers
- Reading time
- 6 min read
- Content review
Scope of this guidance
This note explains selected product behavior and the questions a reviewer can ask. It is not a promise that every workflow, integration, hosting environment, or operational control behaves identically.
Step 1 of 4
Start with the right account and organization
Before a sensitive action moves forward, Pole identifies the signed-in account, its organization, and the record in question. A page can make the work clear, but it does not make an action permissible on its own.
- Check that the organization comes from the signed-in account rather than a value entered in the browser.
- Keep Platform administration, organization staff, and client-portal work separate.
- Explain a blocked or invalid request without exposing private details.
Step 2 of 4
Keep responsibilities clear
Land records, approvals, client relationships, Tenant Finance, and Pole subscriptions have different responsibilities. Keeping those jobs distinct helps a team understand which record or review path should answer a question.
- Use the product action intended for a plot, approval, client, finance, access, or Platform change.
- Keep Tenant Finance for land-sale payments separate from Platform Billing for Pole subscriptions.
- Treat map imagery, payment services, and email delivery as outside services with their own limits.
Step 3 of 4
Review a change before it moves forward
A sensitive change checks the information supplied, the account’s access, and the current record before it can proceed. The record keeps the relevant history for that workflow; the exact history available depends on the action.
- Check that the current organization and record still match the action being requested.
- Review the allowed state changes and any conflict message before trying again.
- Check the history available for this workflow instead of assuming every field change is shown.
Step 4 of 4
Understand what changes next
After an accepted change, the related views can refresh and the right people can see that there is work to review. Those updates help a team continue, but the underlying record remains the place to confirm the result.
- Use an updated record, not an alert alone, to confirm a change.
- Treat an alert as a prompt to review the latest available record.
- Ask separately about hosted behavior, third-party delivery, and measured performance when those matter to your organization.
Final checks
Confirm these points before treating the workflow review as complete.
- The review identifies the product action intended for the change.
- The current account and organization are checked before the action proceeds.
- The available history is described for the individual workflow rather than assumed universally.
- An alert or refreshed view does not replace the record itself.
Continue the review
Continue evaluating this workflow
Review the related Pole workflow, then request organization access when your organization is ready to begin the application. Access is reviewed by Platform and is not created immediately.