April 2026 Release

Qualification Pipeline — Automatic Reconciliation

The qualification pipeline now reacts automatically to every settings change and opportunity update, so reviewers always see the right work without an admin having to nudge anything by hand.

What's new

• Conviction-score threshold change — lowering or raising Minimum conviction score in Qualification settings immediately re-evaluates opportunities. Lower bar: previously skipped opportunities are promoted from Monitoring into your review stages. Higher bar: opportunities that no reviewer has touched yet are demoted back to Monitoring.

• Stage deadline change — changing a review stage's SLA (e.g. from 3 to 5 business days) now propagates to every in-flight review on that stage on save. Shortening no longer produces a surprise batch of overdue reviews; extending pushes the new deadline out immediately. Reviewers stay the same — only the due date moves.

• Opportunity regeneration — when Rembrandt recalculates an opportunity's conviction score (because new signals arrived or the solution profile changed), it now also re-applies the qualification workflow. A rising score moves the opportunity into review; a falling score demotes it; rejected opportunities with expired snooze periods resurface automatically.

• Admin-linked accounts — when an admin links a team member to accounts through the admin panel, reviewer assignments for those accounts are refreshed automatically. Newly assigned reps pick up unassigned reviews without any manual trigger.

Timeline visibility

When a stage's SLA changes, every affected opportunity now shows a dedicated SLA recomputed entry in its qualification timeline, so reviewers can see why a due date shifted without seeing a misleading "reassigned" event.

Safer concurrent edits

If a background pipeline update is running for your organization at the moment you click Advance, Reject or Reassign, you'll see a brief "Pipeline is being updated — please try again" notice instead of a partial save. Retry once the update has settled (typically a few seconds).

Qualification Pipeline — Reassign anywhere + Reset opportunity

Two related changes to how you move opportunities around once they're in flight.

Reassign now works in every non-terminal status

Previously, Reassign was only available while an opportunity was In Review. It now also works on Approved, In Execution, and Executed — useful when a team member leaves, goes on vacation, or you redistribute territories mid-outreach. The action has moved: it now lives in a ⋯ menu next to the assignee name, consistently across the Pipeline tab, My Tasks, and the opportunity detail page. Pick a new person, submit, done.

What stays the same: the candidate list is still filtered by the relevant sales role (the stage's role for In Review; the org-wide Executor role for Approved / In Execution / Executed), and the same permission rules apply (assigned reviewer, territory owner, or sales-role override).

SLA behaviour depends on the status:

• In Review — the stage SLA restarts from "now + stage SLA days", giving the new reviewer a full response window.

• Approved / In Execution / Executed — the existing SLA is preserved. Swapping the executor seat doesn't restart the outreach clock.

Reset an opportunity (Admin / Owner only)

A new destructive action for when a reassign isn't enough — the opportunity needs to start over. Common cases: demo resets, an opportunity that was wrongly approved, or a rejected opp that needs a second opinion from Stage 1 instead of resurfacing on the same stage.

Where to find it: Opportunity detail page → Review Status card → ⋯ menu → Reset opportunity…. The action is intentionally only on the detail page (not on Pipeline or My Tasks rows) and is only visible to Admins and Owners.

Two targets:

• Reset to Monitoring — fully removes the opp from the pipeline. Stage, reviewer, SLA, and all post-approval timestamps are cleared. The opp re-enters via normal enrollment when the score qualifies again.

• Reset to In Review (Stage 1) — drops back to Stage 1 with a fresh SLA. By default auto-assign picks a new Stage 1 reviewer; you can also pin a specific reviewer in the dialog (validated against the Stage 1 role requirement).

What's preserved: scoring, evidence, signal matches, and opportunity history. Past audit entries stay on the timeline and a Reset qualification entry is appended with the previous status, the chosen target, the optional reason you typed, and who performed the reset.

What's wiped: past review decisions for this opp (Advance / Reject records), lifecycle timestamps (execution started / executed / converted / lost), and the "resurfaced from" linkage.

If you reset an opportunity that's currently Rejected, the active rejection snapshot is closed so the automatic resurface jobs don't later drag the opp back to where it came from.

Resurfaced opportunities default to the original rejector

When a rejected opportunity returns to the review queue — whether from a snooze date, new evidence, or a manual Undo rejection — it now goes back to the original rejector by default. They already have the context from the rejection and already made a judgment call, so they're the fastest person to re-evaluate.

If the original rejector has left the org, changed territories, or no longer holds a role that fits the stage, Rembrandt falls back to the normal auto-assign cascade (territory + role + load) and the new reviewer gets the resurface summary instead.

Settings: "Sales role hierarchy"

The old Enforce role-based permissions toggle in Qualification Settings has been relabelled to Sales role hierarchy with a simpler explanation — the question it's really asking is: "Does your org treat BDR < AE < Sales Director as a seniority chain (so higher roles can override lower ones), or as peer roles?" No behaviour change — just clearer wording and a better tooltip.

REST API — Accounts model (breaking)

The REST API has been aligned with the product's Accounts terminology. If you integrate with Rembrandt over HTTP (ChatGPT Actions, Microsoft Copilot Studio, Power Platform, custom scripts, etc.) you will need to update your integration.

What changed

• /v1/companies → /v1/accounts — both list and detail endpoints were renamed. Response wrappers (data.companies[] → data.accounts[], data.company → data.account) and item fields (companyName → name, companyIndustry → industry, companyWebsite → website, companyStatus → status, prospectCount → opportunityCount) follow the same rename.

• /v1/prospects and /v1/prospects/:id were removed. The prospect concept is no longer part of the public API — use /v1/accounts together with /v1/opportunities to access the same data.

• /v1/opportunities filters were simplified. prospectId, companyId, and domainId are no longer accepted; use accountId and solutionId instead. A new accountId filter lets you list every opportunity for a single account in one call.

What you need to do

1. Replace /v1/companies and /v1/prospects URLs in your code and Copilot Studio / Power Platform connectors.

2. Rename company* fields in your response mappers to their account equivalents.

3. Re-import the Rembrandt OpenAPI specification (https://api.rembrandtagents.com/docs/json) in ChatGPT Custom GPTs, Microsoft Copilot Studio, and Power Platform — caches are not refreshed automatically.

Migration details and before/after examples are in the API Changelog.

Qualification Pipeline — Priority cascade and territory enforcement

Two related fixes that tighten how seats end up on the right person, both at advance time and during background re-assignments.

Priority mode now respected on existing seats

When you set an Executor or stage role list to Priority (e.g. [BDR, AE]), the cascade is the rule the system follows top-to-bottom: try the first role first, only fall back when its pool is empty. That rule applied to new assignments before, but existing seats sometimes survived the change with the wrong role on them.

Two scenarios were affected:

• Background reflow — turning on [BDR, AE] Priority on a stage where AE seats were already in place did not push those seats to the BDR pool. Now it does: when a higher-priority pool has a member in territory, the seat shifts on the next reflow run (settings save, regeneration, manual rebalance, etc.).

• Sync approval — a reviewer in a lower-priority role could click Advance at the final review stage and inadvertently end up as the executor, because the actor-preference shortcut bypassed the cascade. Under Priority mode, the shortcut is now skipped and the cascade picks the correct higher-priority candidate.

If you want to keep a specific lower-priority person on a seat regardless of the cascade, use Reassign with Manual reassignments set to "Honour forever" (Admin settings → Qualification → Stability) — your manual pick is then preserved per opportunity.

Territory enforced on every action — no more out-of-territory approvals

Auto-assign already respected territory: a seat could only land on a member assigned to the account, or anyone when the account had no territory configured (greenfield). Manual paths now follow the same rule.

• Approve / Reject / Reassign / Undo rejection / Undo advance — buttons appear (and the underlying mutations succeed) only when the actor is in the account's territory. A Sales Director navigating an opportunity through the All Accounts admin view no longer sees Approve / Reject buttons on accounts outside their territory; the opportunity detail page reads as read-only for them. Greenfield accounts still accept anyone with override role.

• Reassign dialog — the candidate dropdown is filtered server-side. Members outside the account's territory are no longer shown, so a click never produces an "out-of-territory" error toast. The list also adds higher-rank members via the override hierarchy when Enforce role permissions is on.

• Manual reassign — picking a user outside the account's territory is rejected with a clear error. To act on the account, an admin must add that user to the territory first.

The new behaviour matches what the system would already enforce on auto-assign — no path can plant a seat on someone the cascade would never reach.

Audit trail closed on two background paths

Two background paths that previously moved opportunities silently now write a timeline entry:

• Bulk enrollment — when a new pipeline kicks in and many monitored opportunities cross the threshold at once, each one now gets an Entered workflow entry on its timeline.

• Defensive demote — the (very rare) safety-net that demotes opportunities to Monitoring when a stage configuration is missing now writes a Demoted on score drop entry. If you ever see one, escalate to support — it points at a configuration drift.

Audit reasons consolidated under one prefix (support / dashboards only)

Internal change with no UI impact: every background reflow audit row now uses the unified pipeline_reflow_<status>_<reason> naming. Previously some rows used an executor_reflow_* prefix that referred to the executor role, which read as ambiguous next to the IN*EXECUTION status. A data migration renames historical rows in place — older support queries pinned on the old strings (executor_reflow_approved*\*, pipeline_reflow_stage_change, etc.) need to be updated to the new names.