In Build a Workflow with a Coding Assistant, we created the local Position to Job Requisition workflow. It finds positions, lets a user choose one, reviews the requisition details, and creates a requisition only after approval. Now suppose a hiring manager wants to compare a few positions before choosing one. That is a change to the same workflow, not a second workflow.
Before you start
- You’ve built the Position to Job Requisition workflow from Part 6.
- You’ve set up the CLI and your project (Part 3a and Part 3b), and you’re signed in.
- Your coding assistant is open at the AI Studio project root, and you’ve pasted the guardrail request from Part 4.
- You know a business unit ID, a department ID, and a hiring manager’s person ID in your environment. The workflow asks for them, and without real values every lookup returns nothing.
- Your user can read positions and create job requisitions in this environment.
- Not in HCM? Read “Adapt this to your pillar” below first. The steps are the same; only the business example changes.
This article is a design exercise. It shows how to describe and review a change to the workflow from Part 6. The comparison branch hasn’t been built for this article, so there are no screenshots or test results. Run the request yourself, then use “What to check before accepting the change” to review what the assistant built.
One workflow, one new decision
| 1 Look up Use the existing position BO. |
2 Compare Show 2–3 returned positions side by side. |
3 Choose Ask for one exact PositionId. |
4 Rejoin Use the existing review and create route. |
Describe the change in business language
The manager’s request could be: “Compare positions 12045 and 12078 in my business unit and department. Show what Fusion actually says about each, then let me choose one for a job requisition.” The assistant needs to extend the existing route for that request while preserving a direct lookup and creation request.
Try it: Ask your coding assistant to extend the workflow
Use the /aistudio skill to extend the local "Position to Job Requisition" workflow created in the previous exercise. Inspect src/workflows/position_to_job_requisition.wf and its existing position-lookup and requisition-creation Business Objects before editing. Keep the current lookup, selection, approval, creation, error, and out-of-scope behavior working.
Add this scenario: When I ask to compare two or three positions in a business unit and department, look them up through the existing Fusion position Business Object. Ask for missing business unit or department IDs rather than guessing, and ask me to narrow a request for more than three positions. Show a compact side-by-side comparison using only fields actually returned, such as position ID, code, name, hiring status, headcount, and position type when available. Mark unavailable fields as "not returned." Do not invent a vacancy status or describe the limited results as every available position.
Match each requested position to one exact returned PositionId or code, or to one unique exact name. If a position is absent from the limited result, if a name matches several positions, or if the lookup fails, say what happened and ask me to clarify or refine the search. Do not silently choose a position. Comparison by itself must never create a requisition.
After I choose one exact position, continue through the workflow's existing requisition preparation and its existing Human Approval step. Ask for any missing title, numeric hiring manager ID, or positive number of openings. Show the selected position and the existing Business Object's fixed recruiter and location values before approval. Call the existing creation function once only after explicit approval; otherwise create nothing. Report only the result returned by Fusion.
Keep the work local. Validate the edited workflow and run file-based tests for comparison, missing and ambiguous matches, no results, lookup errors, rejection, and the existing direct lookup and create routes. Use fixtures for any write path; do not run a live requisition POST or save/publish to Fusion. Report the files changed, validation results, tests run, and anything the local tests cannot prove.Where the new route joins the old one
| Reuse the read The existing position BO returns at most ten recently updated active positions for the supplied business unit and department. Compare only positions in that returned set. |
Add the decision Show the requested positions in a readable comparison. Pass the chosen, verified PositionId into the existing requisition preparation and review route. |
| Reuse the write gate Keep the current requisition review, fixed-value disclosure, explicit approval, and single create call. A comparison request alone never reaches the POST. |
Preserve the limits The lookup does not prove vacancy or eligibility. A position outside its ten returned rows cannot be declared missing from Fusion. |
That boundary matters: the coding assistant should extend the path after FIND_POSITIONS and rejoin the existing review route, rather than duplicating the requisition-creation node. Inspect the edited graph in VS Code to make sure both the direct route and comparison route reach the same approval step.
What to check before accepting the change
| Request | Expected behavior |
|---|---|
| Compare two returned positions | Shows only returned fields and makes no write. |
| Name matches several positions or one is outside the limited result | Asks for an exact PositionId or refined search; does not guess. |
| Choose one and reject the requisition review | Creates nothing. |
| Use the original direct lookup/create route | Behaves as it did before the extension. |
Local validation can show that the graph is connected and fixture tests can check these paths. A live Fusion lookup, vacancy decision, or requisition creation needs separate verification. The previous article covers the original build, its screenshots, and its test evidence; this article focuses on defining and reviewing the change.
Adapt this to your pillar
The pattern works in any pillar: take a workflow that looks up records and makes one write after approval, and add a step that compares a few of the returned records before the user picks one. The new step only reads; it rejoins the existing approval step. For example: compare two supplier invoices on hold before requesting release of one (ERP), compare items below their reorder point before creating a requisition line (SCM), or compare open service requests before escalating one (CX). Use the request above as a template: replace the workflow name, the records, and the fields to compare.
You’re done when
- Validation reports no errors for the edited workflow.
- Tests for the original lookup and create routes still pass.
- A comparison of two positions shows only returned fields and creates nothing.
- Choosing one position continues to the same approval step as before.
Key takeaways
When you extend a workflow, identify the new decision, the existing path it must rejoin, and the behavior that must still pass. That makes the change request smaller and the regression check clearer.
- Describe only the new decision. Everything else in the request should say what must keep working.
- Ask for tests that cover the old routes as well as the new one, so you can see nothing broke.
Previous: Build a Workflow with a Coding Assistant | Next: Build an Agentic App with a Coding Assistant
Back to the Learning Path for Fusion AI Agent Studio CLI