AMIGO v2.31.0 Release Notes — Spring '26

New Features

Deliverables Workbench: One Grid for Deliverables, Work Packages, Action Items, and Defects

The Deliverables grid on the Project page is no longer a flat list — it's now a three-level tree that shows the whole delivery hierarchy in one place: expand a Deliverable to see its Work Packages, and expand a Work Package to see its Action Items and Defect Logs.

Every level shares the same nine columns — Name, Type, Work Stream, Scope Lever, Resources, Duration, Current Status, % Complete, and an Actions button — with each cell doing the right thing for its row:

• Deliverable rows roll up from their Work Packages, live: Duration sums the children's durations (converted to hours using your organization's working-time calendar), and % Complete averages the children — both update the moment you edit a Work Package underneath.
• Action Item and Defect % Complete derives from status (0% until resolved/completed, then 100%) and is read-only.
• Edit inline: click into Name, Type, Work Stream, Scope Lever, Duration, or a Work Package's % Complete and the change saves immediately — if Salesforce rejects it, you see the real error message and the cell reverts. Current Status stays read-only at every level, since status changes drive the approval engine.
• Work Stream and Scope Lever are set on the Deliverable, so you no longer have to open the record to fill them in. The Work Stream picker lists only the work streams belonging to the project's Program, which is the pairing the Deliverable's own validation rule requires.
• Work Packages follow their Deliverable's Work Stream. Their Work Stream cell shows the inherited value and isn't editable: change it on the Deliverable and every Work Package underneath moves with it, and a newly added Work Package picks it up on creation.
• Resources uses the same assignment picker as the Project Plan Gantt — chips in the cell, a checkbox user picker to edit. Selections save as RACI Responsible entries on Deliverables and Work Packages (multiple allowed; Work Packages cap at three, matching the Project Plan), and as the single Responsible user on Action Items and Defects (picking a second person keeps the last pick). Duplicate assignments are blocked.

Every row has one Actions button opening exactly the actions that apply to its level — Open Record, Edit, Approvals (opening the familiar Work Package and Action Item/Defect modals), and Delete (with a confirmation — deleting a Deliverable cascades to its Work Packages) everywhere, plus Add Work Package on a Deliverable and Add Action Item / Add Defect Log on a Work Package. The same menu opens on right-click anywhere on the row.

Adding records is built into the tree itself:

• "(+ Add new …)" rows at every level: a + Add new Deliverable row at the bottom of the grid, a + Add new Work Package row under each Deliverable, and a combined + Add Action Item / Defect Log row under each Work Package that asks which of the two you want.
• Type the name first: every add path — the header button, the Actions button, right-click, or an add row — inserts a blank row and opens the name editor in place. Pressing Enter with a name creates the record; pressing Esc or leaving the name blank simply removes the row and creates nothing, so an abandoned add never leaves an orphan record behind.
• Add actions follow the workflow: Work Packages can be added only while the Deliverable is in an active working or approval status, and Action Items/Defects can no longer be added once the Work Package's work is approved or the Work Package left scope. Blocked items are greyed out with the reason, and the rule is enforced server-side too.
• Records created from the grid are stamped with the full hierarchy (Organization, Portfolio, Program, Project) from the Project, and their planned start date defaults to today.
• Quick-created records arrive with sensible defaults rather than blanks, since the add row only asks for a name. New Deliverables get Scope Disposition In Scope, Capital/Expense Hybrid, and Scope Lever Not Applicable — all editable afterwards, and Scope Lever right in the grid. New Work Packages get an 8-hour duration and a matching 8-hour Estimated Effort.
• One behavior note: column-header sorting is off in the workbench, so the add rows stay pinned at the end of their sections.

Rounding it out:

• A full-screen button in the header opens the workbench standalone — useful for large trees.
• The header is a single row: title on the left, Add / full-screen / refresh on the right, with the grid starting immediately below.
• The workbench also lives on the Deliverable record page: the Work Packages tab now shows this grid (replacing the previous flat Work Package table), with that deliverable's Work Packages as the top level, Action Items/Defects beneath, and Add Work Package in the header. Note for admins: package upgrades don't modify customized Lightning pages — if you've customized your Deliverable record page, swap in the projectDeliverableGrid component on the Work Packages tab yourself.

Manage Deliverable and Work Package Types Without Leaving Your Work

Deliverable Types and the Work Package Types beneath them are the backbone of the delivery model, but until now the only way to create or change one was to abandon whatever you were doing, navigate to the object's own tab, make the change, and find your way back. There's now a Type Configuration panel that shows the whole taxonomy — every Deliverable Type with its Work Package Types — and lets you manage it in place.

It appears in three places, and behaves identically in all of them:

• a Manage Types button in the Deliverables Workbench header on the Project page,
• a Configuration tab on the Portfolio record page,
• a Configuration tab on the Organization record page, which adds a Portfolio picker at the top since an Organization spans several.

How it works:

• Deliverable Types are compact collapsible sections, and their Work Package Types sit inside as badges. Click a badge to edit that type; the ✕ on it deletes.
• Search covers both levels at once. Matching a Deliverable Type name shows that section with all of its badges intact; matching a Work Package Type name surfaces its parent section, already expanded, showing only the badges that matched. A running count tells you how many of each matched, and clearing the search puts the tree back exactly as you had it, including which sections were open.
• New and Edit open a focused dialog asking only for what context can't supply — Organization and Portfolio are filled in from where you are, so you never pick them, and the Deliverable Type is shown but locked. The Work Package Type form keeps the existing rule: choosing any Special Template other than "Not Applicable" makes the Work Package Template body required.

Types are shared across the portfolio, and deleting one is guarded. A line at the top of the panel names the portfolio the types belong to — a Deliverable Type edited from one Project page changes for every project in that portfolio. Deletion is blocked outright for any type still in use: the Deliverables, Work Packages, Estimates and Program charters pointing at it are counted up front, and Delete is greyed out with that count in its tooltip. This matters more than it sounds, because the underlying lookups blank out silently rather than raising an error — before this, deleting a type in use would have quietly stripped it from every record referencing it, portfolio-wide, with nothing to indicate anything had happened.

Work Package Types that have no Deliverable Type are gathered into an Unassigned section rather than being invisible, and that's the one place the Deliverable Type field is editable, so those records can be given a parent and filed correctly.

Note for admins: package upgrades don't modify customized Lightning pages — if you've customized your Organization or Portfolio record page, add the manageTypesPanel component to a new tab yourself.

Redesigned Theme Selector

The AMIGO Theme Selector in the utility bar has a new look. Themes are now presented as clickable cards, each showing the theme name with a full-width color palette preview — the selected theme is highlighted with a border and check mark, and the whole card is the click target.

• The component themes used by Gantt, Grid, Scheduler, Task Board, and Calendar views (High Contrast, Material 3, Stockholm, Svalbard, Visby) now show color previews too, so you can see each theme's character before applying it.
• One Apply button covers both sections. It stays disabled until you change something, saves only what changed, and confirms success before the page refreshes — if a save fails, you get a clear error and nothing reloads.
• Cards are fully keyboard accessible: tab to a group, use arrow keys to move between themes, and the focus ring shows where you are.

My Favorites, Organized Like the AMIGO Launcher

The My Favorites utility has been rebuilt to match the AMIGO Launcher experience. Instead of a plain list of links, your favorites are now grouped into the same categories the Launcher uses — Organization, People, Process, Technology, and so on — each with its icon, collapsible sections, and a two-column layout.

• A new search bar filters your favorites as you type, with the same behavior as the Launcher's search.
• Favorites that don't belong to a Launcher category appear under Other.
• The Update My Favorites editor works as before: search the available objects, move them between Available and Selected, and your selection order becomes the display order.

System Fields on Business Process and Work Package Forms

The Business Process and Work Package New/Edit forms now let you link a System directly — previously neither form exposed the field at all.

• The System picker stays locked until you select an Organization, then offers only that Organization's Systems, so you can't accidentally pick a System from another Organization.
• If you change or clear the Organization, the picked System is cleared along with it.
• When you edit an existing record, its saved System loads into the picker.

Spreadsheet-Style Mass Edit for Billing & Cost Rates

The Mass Edit & Schedule Rates modal on the Billing Rate And Cost Rate table now works like a spreadsheet:

• Type to edit. Click any cell and start typing — the cell opens for editing with your keystrokes, just like Excel. Double-click still works.
• Drag-fill with the fill handle. Select a cell or range (click-drag or Shift+arrows) and drag the small handle at the selection's corner up or down to copy the values to other users — enter an Effective Start Date, Cost Rate, Cost Unit, Bill Rate, and Bill Unit once, select them, and fill the whole table in one drag. Cost (Hourly) and Bill (Hourly) recalculate on every filled row.
• Filling sideways is blocked (each column is a different field), and the computed hourly columns never accept fills or edits.
• The user column is now read-only — the modal manages rates for exactly the people invited to the Program, one row each, so the lock icons and the user picker are gone.

Effective dates, clarified:

• The Effective Start Date now loads with the rates — each row shows the start date of the user's currently active range.
• The date picker only offers today or later; a saved rate runs ongoing (no end date) until someone schedules a newer effective date, which automatically closes the previous range the day before.
• The validation message now says what it means: "Effective Start Date must be today or later."

Adjusted Effort, Estimate at Completion, and Effort-Based Percent Complete

Work Package effort tracking now follows a classic earned-value model built around a new Adjusted Effort (In Hours) field — a cumulative, signed re-estimation anyone can apply without touching the original estimate:

• Remaining Effort / ETC (In Hours) (the former "Remain Efforts" field, redefined): MAX(0, Estimated + Adjusted − Actual), and automatically 0 once the Work Package is Approved, Auto Approved, or 100% complete. It can no longer go negative.
• New EAC (In Hours): Actual + Remaining — the forecast total at completion.
• New Actual % Complete on Work Package: Actual / EAC, reading 100% once approved — an effort-based complement to the schedule-driven Percentage Complete.
• New Actual % Complete on Project: Σ WP Actual / Σ WP EAC across in-scope Work Packages, maintained by the completion rollup (which now also recalculates when Work Packages are deleted or undeleted).
• Project Percentage Complete is repurposed as "Planned % Complete": the schedule expectation as of today — each Work Package's estimated effort interpolated across its planned window, summed over the total. A new nightly AMIGO Planned Percent Complete Job keeps it current as time passes; it also refreshes with every Work Package change.

The Adjust Remaining Effort section on the Time Report "Add New Effort" modal is now always visible (previously it appeared only when entered hours exceeded the remaining effort) and accepts positive or negative adjustments, alongside a live readout of Estimated, Actual, Adjusted-to-date, Remaining, and EAC. The same Adjusted Effort field is editable from the Work Package New/Edit form and the Gantt's Work Package modal, with the computed values shown read-only. Every adjustment is stamped into the Work Package's Historical Comments and tracked in field history.

The Project Plan Gantt now offers three matching columns — Actual Effort (Hours), Remaining Effort / ETC (Hours), and EAC (Hours) — available from the column header menu's column picker. They're hidden by default and read-only (Actual Effort is maintained by time-tracking rollups; ETC and EAC are computed), and your existing saved column layouts pick them up automatically. The Gantt's Effort column continues to show Estimated Effort only, so enabling the new columns never affects scheduling.

Behavior changes to note:

• Adding extra effort from a time entry no longer inflates Estimated Effort — the baseline (and therefore Bryntum scheduling) stays put; the adjustment lands in the new field.
• Reports or dashboards showing Project Percentage Complete now show the schedule-based Planned % rather than the duration-weighted average of Work Package percent complete (the Gantt's project header included).
• Remaining Effort can no longer read negative on over-worked Work Packages — it clamps at 0, and Percentage of Remaining Effort is now Remaining / EAC.
• Time entries are matched to Work Packages by record Id rather than by name, so identically-named Work Packages can no longer receive each other's hours.
• A new nightly scheduled job is registered automatically on install/upgrade.

Improvements

System Pickers Now Filter by Organization

Systems belong to an Organization, and the System pickers across AMIGO now reflect that: wherever you select a System, the list is filtered by the selected Organization instead of the Program.

• Data Cleansing Tracker: the Associated System picker becomes available as soon as you choose an Organization — you no longer have to select a Portfolio and Program first.
• Create Change Request (from an Issue) and Defect Log (from Test Plan details): the Associated System search now looks within the selected Organization.
• System New/Edit form: creating a System now only asks for its Organization — the Portfolio and Program lookups are gone, matching where Systems actually sit in the hierarchy.

New Organizations Start Ready to Use

Creating an Organization now automatically adds a "Not Applicable" Portfolio and a "Not Applicable" Program (alongside the existing "Not Applicable" Methodology). Records that don't belong to a real portfolio or program hierarchy have valid parents from day one, with no manual setup.

RACI Chart: Next Button Fixed, Plus Previous, a Step Path, and Save Validation

The RACI Chart action — the five-step wizard for assigning Responsible, Accountable, Consulted and Informed users — had a defect that made it unusable on some records: after selecting Responsible users, clicking Next did nothing. No error, no toast, no movement. It struck the first time RACI members were added to a record and affected every object the wizard runs on, not just Deliverables, so the same record could work for one organization and be stuck for another.

The cause was the wizard failing to read its own approval configuration. Where an Organization had no CFG Approval row for that object type, the wizard fell back to a default whose field names didn't match, leaving every "is this role required?" answer undefined — and the Next button had no branch for undefined, so it silently did nothing. Next now advances whenever the role is not explicitly required — and because the "Please select …" message was nested inside the branch that never ran, there was no feedback of any kind either; that message now appears whenever a required role has no one selected.

Alongside the fix, the wizard gained the navigation it was missing:

• A Previous button on every step after the first, so you can go back and correct an earlier role without cancelling and starting over.
• A step path in the footer showing all five steps — Responsible, Accountable, Consulted, Informed, Overview — with completed steps ticked and the current one highlighted. Click any step to jump straight to it. Going backwards is always allowed; jumping forwards runs the same checks Next does, and if a step in between still needs attention you land on that step with its message rather than being refused without explanation.
• Your selections are kept when you navigate. Revisiting a step now shows what you picked, not what was last saved to the database.
• On the RACI Overview step, each role's members now sit side by side and wrap, instead of one per line. A role with several members no longer pushes the rest of the summary out of view.

Save now respects your approval configuration. If you remove every member of a role that your CFG Approval configuration requires — the case that previously saved silently, leaving a required role with nobody in it and an approval that could never complete — Save is blocked with a message naming the role. Roles your configuration doesn't require are unaffected, and records in organizations with no approval configuration at all continue to save freely.

Approval Configuration Backfilled on Upgrade

CFG Approval records were only ever created at the moment an Organization was created. Any object type added to AMIGO afterwards was therefore never configured on Organizations that already existed, and an Organization whose creation-time setup didn't complete stayed unconfigured indefinitely — which is what left the RACI Chart with no configuration to read.

• Upgrading now creates any missing CFG Approval rows for every Organization, covering object types added after the Organization was created. It only fills gaps, so configuration you have already tuned is left exactly as it is, and it is safe to run repeatedly.
• Benefit is now a configurable approval object. It was missing from the setup list entirely, so no Organization ever received a Benefit row and the RACI Chart on a Benefit record had no configuration to read — this was the single most affected object.
• Failures while creating these records are now reported to the debug log instead of being discarded, so a permission problem during setup is no longer indistinguishable from success.

My Favorites Reliability

• Users whose favorites were seeded automatically from their AMIGO Role no longer see an error when opening My Favorites — the panel now renders correctly the first time, before the user has ever saved a custom order.
• The Test Plan Details favorite now navigates to its tab correctly (previously the link was broken).

New/Edit Forms: Missing Save/Cancel Footer Fixed

Opening the Edit form on certain records used to leave the form unusable — the Save/Cancel footer and the Historical Comment section simply didn't appear, so changes couldn't be saved. The culprit was saved multi-select picklist values breaking the form's rendering partway through. The affected forms now load saved selections correctly and render in full:

• Communications Register (Communication Event, Frequency, and Medium)
• Program Financial (Sensitive Data)
• Deliverable (Sensitive Data)

Historical Comments Appear on the Feed Immediately

Saving a record with a Historical Comment now shows that comment on the record's activity feed right away. Previously the comment was saved correctly, but the feed kept showing cached, pre-save data until the browser cache expired or the page was hard-refreshed — which looked like the comment had been lost. The feed now fetches fresh data on every view and reloads itself whenever the record changes.

Related hardening that shipped with this fix:

• Failures while posting a Historical Comment (or clearing its staging field) are now logged to the Custom Exception tab instead of being silently swallowed, and bulk failures are logged in a single batch so large operations can't hit governor limits.
• On Work Package, re-submitting the same comment text posts it again, matching how Deliverable and Issue Log behave; and if a save fails outright, the form now shows an error instead of a false success message.
• Historical Comment records are stamped with the Generic record type on every object, consistently.
• One-time note for existing orgs: if a Work Package was left holding an old un-posted comment (from a historical failure), that comment posts once on the record's next update and the field is cleared.

My Dashboards: the Filter Now Filters Everything

The Apply Filter header on My Dashboards had several long-standing defects that made results incomplete or one step behind — most visibly on the My Workspace tab, where filtering by a project could leave the work queue nearly empty even though you had open Work Packages assigned. All of them are fixed:

• Filters apply immediately. Applying a filter used to query with the previous filter selection — the new one only took effect on the next apply or tab switch, which looked like a caching problem. Every tab (My Workspace, My Approvals, Risk/Issues/Actions, Lessons/CRs/Key Decisions, Projects/Deliverables/Work Packages, My Messages) now receives the fresh filter value the moment you click Apply.
• The hierarchy filter matches on real relationships. The filter previously matched some objects on text formula fields that can never equal a record Id — on Work Package the Organization and Portfolio levels were dead clauses, and Issue Log's Project level compared against the project name. The filter now validates fields against the schema, Work Package filters through its actual Organization/Portfolio lookups, and Issue Log filters projects through its Projects Issue Log junction, so multi-project issues match every project they're linked to.
• The filter follows the hierarchy. Because Organization → Portfolio → Program → Project is a cascade, the filter now applies your deepest selection (objects without that level fall back to the next one up). Previously every level was applied at once, which wrongly hid records whose Organization/Portfolio lookups were blank — common on data loaded through the API with automation disabled.
• My Workspace shows your open work first. Closed items are now excluded in the query itself rather than after the per-object 500-record cap. Heavy users could previously see mostly-empty segments because the cap filled up with old closed records; the cap now applies to open work only, and the "showing the first 500" notice is accurate.
• The date range means due dates. On My Workspace, the From/To filter now windows each item's due or planned date (Work Package planned end, Action Item and Issue due dates, Defect estimated resolution) instead of its created date — an open item created long ago no longer vanishes from a current date range. Items with no due date always stay visible, and Deliverables and Test Plans (which have no due date) are no longer date-filtered.

Mass Edit Saves at Any Program Size

• Saving bulk rates used to run one save per user, which consumed Salesforce resources linearly — programs around eight users already drew "SOQL queries: 65 out of 100" governor warnings, and larger programs would have failed outright. The save is now a single bulk operation with a flat query cost (measured at 8 of 100 for a full-table save), no matter how many users the Program has. A validation failure now saves nothing at all, instead of leaving earlier rows half-saved.
• Fixed a timezone bug where the Effective Start Date could save one day earlier than the date shown in the grid for users in timezones ahead of UTC (e.g. IST).

Save Errors Now Show the Real Message

A failed save on an AMIGO New/Edit form used to look like a success: the form showed a green "saved successfully" toast, then tried to open the record that was never created and landed on a broken "No URL Exist" page — the only clue to what went wrong was buried in the Custom Exception tab. This affected roughly forty forms, including Gate, Issue Log, Risk Register, Key Decision, Portfolio, Program, Work Package, and Meeting Minutes.

• Every save failure now shows the actual error — the same message Salesforce produced, whether it's a validation rule, a missing required field, or a permission problem. If several things are wrong at once, the toast lists all of them.
• Error toasts now stay on screen until you dismiss them, so a long validation message can't vanish before you finish reading it.
• No more "please check the Custom Exception tab" detours — the tab still receives the detailed log for admins, but the person saving sees the reason immediately.
• Two forms that silently ignored save results altogether — Data Domain and Strategic Datum — now report failures like the rest.

Work Packages Added From the Workbench No Longer Start at Zero Effort

A Work Package created from the Deliverables Workbench was saved with an Estimated Effort of 0, even though it was given an 8-hour duration at the same time. Nothing corrected it afterwards, so unless someone opened the record and typed a number, it stayed at zero — and because Estimated Effort feeds Remaining Effort, EAC, and the new planned-percent rollup, those Work Packages quietly contributed nothing to any of them.

Estimated Effort now tracks the duration:

• On creation, it matches the 8-hour default duration.
• When you edit Duration in the grid, effort follows in the same save, converted to hours by the row's duration unit — hours as-is, minutes divided by 60, and days scaled by the Hours Per Day on the project's working-time calendar rather than an assumed 8.

One thing to know if you also use the Gantt: the Project Plan Gantt still derives effort from duration × assigned RACI units and writes that back when you save it. For a Work Package with a single Responsible at 100% the two agree; with none or several assigned, a Gantt save can move the value away from the duration.

Under the Hood

Legacy Component Replacement

• The Aura component behind My Favorites (RoleBasedRoadMap) no longer ships with the package — it has been fully replaced by the myFavorites Lightning Web Component. On upgrade, existing orgs keep a deprecated copy in place; fresh installs receive only the LWC. Its Apex controller is retained and reused by the new component.
• The AMIGO Launcher's category and navigation data has been extracted into a shared roadMapMenuData service module, so the Launcher and My Favorites present one consistent catalog.

System Field Metadata

• The field-level Program lookup filters were removed from six System lookup fields: Current System and Future System on Change Impact Assessment, and Associated System / System on Change Request Log, Data Cleansing Tracker, Defect Log, and Work Package. For the latter four, filtering now happens at runtime in the AMIGO forms, keyed to the selected Organization. Note for admins: standard lookup dialogs on your own layouts no longer pre-filter by Program — and the Change Impact Assessment System lookups, which have no custom form, are now unfiltered.

Billing Rate Save Bulkified

• BillingAndCostTableViewController now routes both save paths (single-row Update / Schedule Rate and the Mass Edit bulk save) through one bulk engine: one query per object for the whole batch and at most five bulk DML statements, so the rate-table triggers and Apex sharing recalculation run once per statement instead of once per user. Ranged-rate semantics are unchanged.
• New test class BillingAndCostTableViewControllerTest covers the bulk save, range supersession, single-row saves, and validation errors, and asserts the flat SOQL profile as a regression guard.

Save Path Consolidated Behind One Error-Surfacing Method

• New CustomExceptionHelper.upsertOperationOrThrow is now the canonical save path for @AuraEnabled form saves: it logs failures to the Custom Exception tab exactly like upsertOperation, then throws an AuraHandledException carrying every distinct DML error message so the client toast shows the complete story. 44 save call sites across the AddHelper / NewAndEditController classes were converted to it (the swallowing upsertOperation remains only for fire-and-forget Queueable rollup paths, where it is intentional).
• showToastMessage in amigoLwcServices accepts an optional toast mode; the New/Edit save handlers use it to make error toasts sticky.
• Two test classes were fixed whose "successful save" test data had never actually saved (masked by the old silent-swallow behavior): Meeting Minutes was missing its required Meeting Date Time, and Program Financial exceeded the Rate field's range and tried to insert a second Program Financial for a Program that already had one.

Deliverables Workbench Internals

• The projectDeliverableGrid LWC was rewritten from a flat bryntumGridBase Grid into a self-contained Bryntum Gantt used as a tree grid (timeline pane collapsed), with resources and assignments flowing through Bryntum's native ProjectModel stores — the same architecture as the Project Plan Gantt.
• ProjectDeliverableGridApex was extended accordingly: fetchWorkbenchData now returns the full three-level tree (with RACI resources) and accepts a Project or Deliverable Id for the two placements; new methods cover per-object creation with status gates (createWorkPackage, createChildItem), whitelisted inline saves (updateTreeRows), Responsible-resource diff sync (setResponsibleUsers), and a generic deleteTreeRecord that unlocks approval-locked records first (absorbing the old deleteWorkPackage). All paths keep WITH USER_MODE and the upsertOperationOrThrow error-surfacing convention.
• ProjectDeliverableGridApexTest grew to eighteen tests covering the tree fetch in both placements, both creation gates, mixed-object inline saves, RACI add/remove sync, per-object deletes, the quick-create field defaults, Program-scoped work stream lookup, and the effort seed and conversion.
• The Work Stream and Scope Lever columns added a fetchWorkStreams endpoint that resolves the project from any supported record Id and filters work streams to that project's Program — the scoping is what keeps the picker from ever producing the cross-program pairing DelivProgequalstoworkStream_Prog rejects. Scope Lever reuses the shared fetchPicklistValues service rather than adding an endpoint. updateTreeRows' whitelist widened by three keys: workStreamId and scopeLever on Deliverable, estimatedEffort on Work Package. Work Stream is deliberately not writable on Work Package — WorkPackageTriggerMapping.beforeInsert and DeliverableTriggerHelper.workStreamUpdateInDeliverable already own that copy-down, and createWorkPackage now also stamps it explicitly so the row returned to the grid is correct even if trigger automation is switched off.
• Duration-to-hours conversion for the effort write happens client-side, through the calendar-aware HOURSPERUNIT helper the component already used for its Duration rollup — the one converter in the codebase that covers the exact Duration_Unitc domain and reads Hours Per Day from Calendarc. Reusing it avoided adding another divergent conversion table; the grid's rollup and its effort writes now share one.
• The workbench's interaction rework (right-click menu, "(+ Add new …)" rows, type-the-name-first creation) is entirely client-side: the right-click menu uses Bryntum's taskMenu feature, the Actions column is a WidgetColumn hosting a native Bryntum Button, new rows start as client-only placeholders that call the existing create* methods only on commit, and the add rows are sentinel nodes injected during the tree build. ProjectDeliverableGridApex is unchanged.

Type Configuration Internals

• New ManageTypesController backs the panel. fetchTypeTree resolves scope from an Organization, Portfolio, Project, Deliverable or Work Package Id — only Organization leaves the portfolio unset and returns a picker list — then returns the two-level tree plus five COUNT(Id) aggregates (Deliverables, Work Packages, Work Package Type Estimates, Program charters, and child type counts) in one round trip, so the client can disable deletion up front. It is deliberately not cacheable: the panel writes and immediately re-reads, and a cached read would serve pre-save data. deleteType recomputes the same counts server-side rather than trusting the client's disabled state. No new save method — NewAndEditDeliverableTypeController.saveRecord and AddWorkPackageTypeHelper.saveRecord are reused, so saves keep routing through upsertOperationOrThrow.
• Three components, one behaviour: manageTypesPanel holds all the logic and markup and is the only piece with an isExposed meta; manageTypesModal and the two flexipage tabs are thin mounts around it, and manageTypeFormModal owns the New/Edit forms. The forms live in their own modal specifically so their Cancel/Save land in a real lightning-modal-footer — rendered inside the panel they stacked underneath the host modal's own footer, producing two visible footers.
• The accordion is the SLDS blueprint (slds-accordion / slds-accordion__section / slds-is-open) with a hand-wired toggle rather than lightning-accordion. The compact density the design calls for lives in the base component's shadow DOM and is exposed by no styling hook, so parent CSS cannot reach it under Lightning Web Security.
• The Deliverable Type field is a lightning-record-picker, disabled with value still bound so the record name resolves (following newAndEditWorkstream). It is enabled only for a parentless Work Package Type, where its filter scopes the search to the current portfolio — without that the picker would offer types the field's own lookup filter would then reject. Note it reports selections on event.detail.recordId, not event.detail.value.
• Form fields are keyed off data-field rather than name, because lightning-input-rich-text exposes no public name property and LWC logs an "Unknown public property" warning for it. The roughly forty existing newAndEdit* components still read event.target.name on their rich-text fields, which is undefined there — tracked separately.
• 23 Jest tests across the panel and form modal (including a regression test asserting no buttons render inside lightning-modal-body) and 10 Apex tests covering every scope-resolution entry point, the portfolio override, and both blocked-delete paths. ManageTypesController sits at 95% coverage.

RACI Chart Wizard Internals

• The dead Next button came from a namespace find/replace that rewrote the c suffix as amigo1 in the fallback approval-config object inside RaciCharNewDesignController.js, so cfgValues.amigo1Responsiblec read undefined while every gate tested strict equality against true or false. Those gates now use === true with a plain else, so false and undefined both advance and no future undefined can dead-end the wizard. The same corruption remains in four unrelated places (portfolioEvaluationRequest, DetailPageCustomLookUpController, CTDNewEditOverrideTest, ChangeRequestLogPieChartController) and is tracked separately.
• All three doInit callbacks now check response.getState(). A server failure was previously indistinguishable from "no configuration", and getInsertedRaciUsers dereferenced its result unguarded, throwing a TypeError that silently left the user picker empty.
• getCheckboxValuefromProgram threw an uncaught QueryException for Benefit, Business Process, Job Role, and Program Financials with no Program: none has a reference field matching program__c, so the generic lookup fell through to a sentinel meaning "this record is a Program" and queried Programc by a non-Program Id. The single-row assignment is now a list, the sentinel is restricted to Programc itself, Benefit resolves via Program_Financialr.Programc, and Business Process and Job Role short-circuit since neither relates to a Program.
• The wizard's step definitions became an ordered array, so previous/next/jump all derive from position — the previous shape was a forward-only linked list where each step knew only its next. Navigation, step-entry validation and save validation now share one table, and the footer path is generated from it.
• Step pickers are re-seeded from v.selected*Records rather than the doInit database snapshot. The old source was never updated after load, so re-entering a step reset it to what was last saved — invisible while navigation was forward-only, and a data-loss bug as soon as Previous existed.
• The footer path is hand-rolled slds-path markup rather than lightning:progressIndicator; lightning:progressStep is Beta and has no click event, and building a clickable element that sets the current step is the documented workaround. It follows the existing DualChevron precedent for an interactive path, with donutSummaryCard's data-attribute dispatch in place of one handler per step.
• Save validation supersedes a block that had been commented out with a note disabling it per stakeholder request. That version was guarded on the existing-row count, so it only fired on records with no RACI rows yet — the reason emptying a required role on an established record saved silently. The replacement tests the final selection for every role regardless of prior counts and re-checks the single-user rule, which free forward navigation could otherwise bypass.

Approval Configuration Setup

• OrgCFGApprovalAutoCreateHelper gained an idempotent backfillMissingCFGApprovals, which diffs existing (Organization, Approval Object) pairs against AmigoMetadataMapping.getCFGConfigs() and inserts only what is missing, chunked to stay inside DML limits. AMIGOPostInstallScript.executeEssentialTasks calls it on every install and upgrade, following the createRequiredPublicGroups pattern, so existing orgs self-heal and the next object added to the map cannot strand them again.
• Database.insert(..., false, …) discarded its SaveResult[] inside a catch that only called System.debug, making a total failure — including a USER_MODE permission gap — indistinguishable from success. Failures are now collected and logged with their status codes. Insert-time and backfill paths share one row builder so their defaults cannot drift.
• amigo1Benefitc was added to getCFGConfigs(), and Benefit to the Approval_Objects global value set — it was absent from both, so the value could not even be selected on a fresh install.
• New OrgCFGApprovalAutoCreateHelperTest covers auto-create coverage, backfill idempotency (a second run must insert nothing) and the empty-trigger-list case; ControllerAddRACILightningTest gained three tests asserting getCheckboxValuefromProgram returns null instead of throwing.

Release Metadata

• Version 2.31.0.1 — subscriber package version 04tOS00000MI0krYAD, ancestor 2.30.0, Apex code coverage 77%.
• Release notes URL (baked at version create): https://goamigo.co/release-notes/amigo-v2-31-0-release-notes-spring-26/