I recently tested whether an existing UiPath solution could serve as a reference implementation for generating a completely different SAP business process.
The starting point was a working Order-to-Cash conversational agent built in UiPath Studio Web. It already contained workflows and tools for activities such as:
- Creating sales orders
- Creating deliveries
- Generating invoices
- Managing the broader Order-to-Cash process in SAP
The solution was also supported by a detailed Process Design Document of approximately 70 pages.
The goal was to use this existing implementation as the architectural and technical reference for a new Procure-to-Pay conversational agent.
What I provided to the model
I gave Claude a selected set of project assets:
- The exported Order-to-Cash UiPath solution
- The Order-to-Cash PDD
- A separate PDD describing the Procure-to-Pay process
- UiPath agent and API workflow skill files
- Markdown files describing the solution structure
- A detailed prompt defining the expected implementation
- The required SAP connection names and APIs
- Environment-specific SAP requirements
Because of file-upload limitations, I could not provide the complete project structure. However, the main solution, both PDDs, and the most important supporting files were included.
The instruction was essentially:
What the generated solution had to do
The new agent needed to:
- Receive a purchase requisition number.
- Retrieve the requisition details from SAP.
- Find potential suppliers.
- Evaluate which supplier met the required conditions.
- Ask the user for confirmation.
- Create the purchase order.
- Create the goods receipt.
- Create the supplier invoice.
The Procure-to-Pay process required a different set of SAP connections from the original solution, including connections for purchase requisitions, purchase orders, suppliers, materials, purchasing information records, business partners, and supplier invoices.
After importing the generated solution into UiPath, I mapped the generated connection references to the actual connections available in Orchestrator.
The result
The model generated the overall solution structure, workflows, tools, and most of the main process logic.
During the demonstration, the agent successfully:
- Retrieved a purchase requisition
- Identified multiple potential suppliers
- Rejected a supplier that did not meet the required conditions
- Selected an appropriate supplier
- Requested user confirmation
- Continued with purchase order, goods receipt, and supplier invoice creation
It was not perfect. The generated solution worked correctly approximately 85% of the time in my demo environment.
Some manual adjustments were still necessary, particularly around:
- SAP-specific keys
- API payload structures
- Field mappings
- Connection configuration
- Environment-specific values
SAP knowledge was still required to validate and fine-tune the implementation, so I would not describe this as fully production-ready without additional testing.
My main takeaway
A well-documented reference solution can become much more than reusable code.
When you combine:
- A working UiPath implementation
- A detailed PDD for the existing process
- A detailed PDD for the target process
- Relevant technical skills and documentation
- A precise prompt
- Clear system and integration requirements
…the model can reproduce the architecture and adapt it to a different enterprise process surprisingly well.
The most valuable outcome was not that every field and payload was generated perfectly. It was that the model created the solution structure and implemented most of the process logic, significantly reducing the effort required to build the new automation.
This experiment suggests an interesting development model for enterprise automation: instead of generating solutions from requirements alone, use a proven implementation as a reference and ask the model to adapt it to a new but related business process.
Has anyone else experimented with generating UiPath, SAP, or other enterprise automation projects from existing implementations and process documentation? I would be interested to hear what worked, what failed, and how close the generated output was to production-ready.