Documentation Index
Fetch the complete documentation index at: https://parabola.io/docs/llms.txt
Use this file to discover all available pages before exploring further.
Prowork Best Practices
Prowork gets better results when you give it better context. These practices come from patterns we see across thousands of workflows.Describe the outcome, not the steps
Tell Prowork what you want to end up with, not how to get there. Less effective:“First pull from Google Sheets, then filter rows where status is ‘shipped,’ then combine with the Shopify export, then add a column that calculates the difference.”More effective:
“I need to reconcile shipped orders between our Google Sheets tracker and Shopify. Flag any order where the shipped quantity doesn’t match what Shopify shows.”Prowork knows which steps to use. Your job is to describe the data and the business logic.
Be specific about your data
Name your sources, columns, and formats. The more concrete you are, the fewer follow-up questions Prowork needs to ask. Vague:“Clean up the vendor data.”Specific:
“I get a CSV from our 3PL every Monday with columns: SKU, Qty_Shipped, Ship_Date, Tracking_No. The date format is DD/MM/YYYY. I need to match this against our Shopify orders by SKU and flag any quantity mismatches.”
Mention edge cases upfront
If you know your data has quirks, tell Prowork before it builds:- “Some invoices have line items split across two pages”
- “The vendor sometimes sends quantities as text (‘five hundred’) instead of numbers”
- “About 10% of the rows have blank tracking numbers, and those should be flagged, not dropped”
Iterate in small steps
If the first version isn’t right, don’t start over. Refine:- “Change the filter to include ‘partially shipped’ orders too”
- “The date column is parsing incorrectly. The format is DD-MMM-YYYY, not MM/DD/YYYY”
- “Add a summary row at the bottom with totals for each column”
Use exact column names
When referring to data columns in your prompts, use the exact names from your source. If the column is calledQty_Shipped, say “Qty_Shipped,” not “quantity shipped” or “the shipping quantity column.”
This is especially important for Custom Transform steps, where ambiguous column references can lead to Prowork guessing.
Break complex processes into phases
For large workflows (10+ steps), build in phases:- Phase 1: Ingestion. Get all your data sources connected and pulling in correctly.
- Phase 2: Cleaning. Standardize formats, handle missing values, deduplicate.
- Phase 3: Transformation. The core logic (matching, calculating, categorizing).
- Phase 4: Output. Send results to the destination (Google Sheets, email, ERP, database).
Review Prowork-built steps before scheduling
Before setting a flow to run automatically:- Run it once with real data and check every step’s output
- Look at edge cases (the rows that are unusual, not just the clean ones)
- Verify the output matches what you’d produce manually
- Set up failure notifications so you know if something breaks
When Prowork gets stuck
If Prowork can’t build what you need:- Simplify the request. Break it into two smaller requests.
- Provide an example. “Here’s what the output should look like for row 1: [example]”
- Build that step manually. Use the native step library for the tricky part and let Prowork handle the rest.
- Use the Experiment step to test whether Prowork can handle your specific data before committing to a full step.
Common patterns that work well
| Pattern | Example |
|---|---|
| Reconciliation | ”Match orders from system A against shipments from system B, flag discrepancies” |
| Data extraction | ”Extract vendor name, invoice number, line items, and total from these PDF invoices” |
| Report generation | ”Summarize this week’s orders by region, calculate growth vs. last week, send to Google Sheets” |
| Data cleaning | ”Standardize company names, remove duplicates, fill missing zip codes from the address” |
| Exception handling | ”Flag any transaction over $10K, any duplicate invoice number, or any vendor not in our approved list” |