Issue Summary: Approval Request Not Generated When Moving Existing Projects to Transition
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
15 hours ago
During testing in the Dev and Test environments, an issue has been identified where approval requests are not automatically generated when moving existing projects between phases.
Observed Behaviour
- When an existing project is moved from the Delivery phase to Transition using “Move to Transition”:
- ✅ The project phase updates correctly
- ❌ The second approval request that should be automatically created does not appear under the Approvals tab
Expected Behaviour
- Upon moving a project from Delivery → Transition, a new approval request should be automatically generated and visible under the Approvals tab, as happens in Production.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12 hours ago
1. Identify the Approval Generation Mechanism
First, figure out what creates the approval in Production. Check these in the Production instance:
- Business Rules on the project table (e.g.,
pm_projector your custom table) that fire on phase update — filter bycurrent.phase.changesTo()or similar conditions. - Flow Designer Flows / Workflows — look for flows triggered by record update on the project table with a condition matching the Delivery → Transition phase change. Check under Flow Designer → Flows and also legacy Workflow Editor.
- Approval Policies — navigate to
sysapproval_policyand look for policies scoped to the project table with phase-based conditions.
Once you find the mechanism in Prod, check whether it exists and is active in Dev/Test.
2. Most Likely Culprits
Since the phase does update correctly but the approval doesn't generate, the transition logic itself is fine — it's the downstream trigger that's broken. Common causes:
- Inactive Business Rule or Flow — the BR/flow was deactivated in sub-prod during prior testing or an update set brought it over in an inactive state. Check the
activeflag. - Update Set / Scoped App Version Mismatch — if this lives in a scoped app, confirm the same app version is installed in Dev/Test. A missing or older version could lack the approval rule entirely.
- Condition Mismatch — if the approval trigger checks a phase value by sys_id (e.g.,
current.phase == 'some_sys_id'), those sys_ids differ across instances. This is the most common cross-environment breakage. Verify the sys_ids for "Delivery" and "Transition" phase records match what the BR/flow expects. - Missing Approval Group or User — the approval rule fires but the group/user it assigns to doesn't exist in Dev/Test, so the approval record silently fails to create.
3. Quick Diagnostic Script
Run this in Scripts - Background on your Dev/Test instance to check if any approval-related Business Rules exist and are active on the project table:
var gr = new GlideRecord('sys_script'); // Business Rules
gr.addQuery('collection', 'pm_project'); // adjust table name if different
gr.addQuery('script', 'CONTAINS', 'approval');
gr.query();
while (gr.next()) {
gs.info(gr.name + ' | Active: ' + gr.active + ' | When: ' + gr.when);
}
Do the same for Flows:
var gr = new GlideRecord('sys_hub_flow');
gr.addQuery('trigger_table', 'pm_project');
gr.addQuery('active', true);
gr.query();
while (gr.next()) {
gs.info(gr.name + ' | Active: ' + gr.active);
}
4. Validate the Approval Record Itself
Also check whether the approval is being created but just not showing under the Approvals tab (a related list configuration issue):
var gr = new GlideRecord('sysapproval_approver');
gr.addQuery('document_id', '<your_project_sys_id>');
gr.orderByDesc('sys_created_on');
gr.query();
gs.info('Approval count: ' + gr.getRowCount());
while (gr.next()) {
gs.info(gr.sys_created_on + ' | State: ' + gr.state + ' | Approver: ' + gr.approver.getDisplayValue());
}
If records exist, then the issue is the related list config on the form, not the approval logic.
5. Recommended Fix Path
Once you identify which mechanism creates the approval in Prod, do a targeted comparison — export the specific BR/flow/approval policy from Prod and diff it against Dev/Test. Focus on: active state, conditions (especially sys_id references), and any approval group/user references.
