How Portal Fixer applies a change
Portal Fixer is software for small B2B teams with no HubSpot admin. It applies catalog items from a Portal Audit fix plan.
1. Start from the fix plan
Import the fix plan from Portal Audit. Items in the Fix Catalog can be dry-run. Items outside the catalog stay on the report for you to handle yourself.
2. A dry run re-reads the portal
Portal Fixer reads the current values and builds a diff. A dry run does not change the portal. Each row is one field: where it lives, the value there now, and the value that would be written.
3. Four reversible types are policy-approved. The rest of this list waits for a person.
Before a write, Portal Fixer reads the current values and shows a dry-run diff. Reversible description rewrites, custom-group moves, company-name backfills, and quarterly stage-probability updates are recorded as policy-approved for that change set under their playbooks. They do not wait for a separate approval.
These still wait for a person's approval of that exact diff:
- Stage renames, and adding or removing a stage
- Renaming a property group
- Creating or editing a workflow
- An owner assignment that gives more than 100 records to any one user
A run that would go beyond an item's limits does not happen automatically. Turning a fix type on is not itself a write. The portal still has to match a fresh read before Apply.
4. Writes are off by default
Writes ship off. A dry run can finish, and an approval can be recorded, and Apply still does not write while writes are off. A portal can also turn any fix type off. A type that is off does not run.
5. Apply checks, snapshots, writes, and reads back
When writes are on, Apply checks that the portal still matches the approved diff. It stores an encrypted snapshot, writes only the allowlisted fields for that fix, and reads the result back on a separate request. If the stored value does not match what was approved, Portal Fixer restores the snapshot and flags the fix.
6. Rollback
You can roll a change back from the snapshot. Snapshots are kept 90 days by default, then deleted. A workflow that was created cannot be deleted: rollback does not remove it, and the workflow is left off.
7. Caps
A practice run stops at 100 records, the per-run cap, or the fix type's own limit, whichever is lowest. An approved change set that would touch more than 500 records in one run is refused, not split into smaller runs, unless that default was changed for that portal. There is no monthly record cap. The caps published for a paid plan are on the Portal Audit pricing page. This page does not set a separate price.
8. Workflow side effects
If the optional automation permission was granted, the diff names workflows whose enrollment filters use the property being changed. If it was not granted, the diff says workflow side effects were not checked. Portal Fixer does not turn a workflow on.
9. What each fix changes
| Fix | What is written | Who approves |
|---|---|---|
| Custom property descriptions | The description field only | Policy-approved for that change set when the rewrite is reversible. No separate approval |
| Property groups | Group membership, or a group's label | Policy-approved for a move. A person approves a rename of that exact diff |
| Contact company name | The contact's company property only | Policy-approved for that change set. No separate approval |
| Deal stage labels | The stage label. An add also sets its order and a starting probability | A person approves that exact diff |
| Deal stage probabilities | The stage probability, inside the quarter window | Policy-approved for that change set inside the quarter window. No separate approval |
| Deal and ticket owners | The owner field | A person approves that exact diff when more than 100 records go to any one user |
| Assignment workflow | A workflow skeleton that is left off | A person approves that exact diff |
Stage probabilities use the fiscal start month saved for that portal. The default is January. The quarter window is the first 14 days.
Deal stage changes do not include a message sent to your team. A draft note can be prepared for you to send yourself. Entrance and exit criteria can be drafted for you to paste into HubSpot. Portal Fixer does not paste them.
10. AI steps
Some steps ask for a yes-or-no, a choice, or a sentence, such as a property description. Counts and lookups stay in ordinary code. For descriptions, record values are not sent to that step. If a step is not answered, it is skipped. Portal Fixer does not invent a yes, a choice, or a sentence.
What it never does
Deletes are refused, including on a test portal. Portal Fixer does not merge records, turn a workflow on, send email, or change billing, users, or permissions.
Customer portals are not written until the Terms are published and the Fix Catalog on the setup guide is the published catalog. The Terms on this site are still a draft.