Custom Code in Workflows: How the AACFlow Function Block Lets You Run Any JavaScript or Python

The block receives data from previous workflow nodes as named input variables. When your code finishes, whatever you return becomes the output of that block — available to every downstream node in the workflow, fully typed and inspectable in the execution trace.

Key characteristics:

• Sandboxed execution — isolated-vm isolates JavaScript from the host Node.js process; Python runs in a restricted subprocess
• Inputs from the DAG — previous block outputs are injected as variables automatically
• Any return shape — return a string, number, array, or deeply nested object; downstream blocks get it all
• File support — pass files into the function and return processed file results
• No external package installs — standard language APIs are available (built-in fetch, standard library modules), but you cannot npm install or pip install at runtime

Running JavaScript in Your Workflows

JavaScript in the Function block is the go-to choice for JSON manipulation, date arithmetic, and lightweight data transformations. Because it runs in a V8 isolate, it feels like writing normal JavaScript but with a tightly controlled scope.

Here is a real example: an invoice processing workflow receives raw line items from a PDF extraction step, and the Function block cleans and totals them.

The downstream Google Sheets block receives this object directly and writes each field into the right column. No schema mapping step needed — the shape you return is the shape downstream blocks see.

A second common pattern is calling an external API that AACFlow does not have a dedicated connector for:

Running Python for Data Processing

For heavier data manipulation — statistical analysis, regex-heavy text processing, or structured data extraction — Python is often the better choice inside AACFlow. The Python runtime gives you access to the standard library, including re, json, csv, datetime, math, and collections.

Here is an example: a workflow pulls a raw sales CSV from S3, and the Function block aggregates it before sending to a reporting dashboard.

This returns a clean array of region summaries. The next block — a Slack message or a Google Sheets write — receives it without any additional transformation.

Python is also excellent for regex-intensive extraction from unstructured text that comes back from AI model blocks:

Building Reusable Custom Tools

Writing the same parsing logic in every workflow is not sustainable. AACFlow's Custom Tools feature lets you save a Function block as a reusable tool in your workspace. Once saved, Custom Tools appear in the tool selector for any AI Agent block in your workspace — your agents can call them by name just like any built-in tool.

The flow:

1. Write and test your function logic in a Function block
2. Define a clear name, description, and typed input schema
3. Save it as a Custom Tool in workspace settings
4. Any AI Agent in the workspace can now call that tool when needed

This is especially powerful when combined with the AI Agent block's tool-use capabilities. Your agent can decide at runtime whether to call a built-in connector, a Custom Tool you've saved, or a combination of both — all driven by the task at hand.

Combining the Function Block with AI Agents

One of the more advanced patterns in AACFlow is dynamic code generation: an AI Agent block writes JavaScript or Python code in response to a user request, and a Function block immediately executes it.

The pattern looks like this:

1. User input → describes a data transformation in plain language
2. AI Agent block → generates the JavaScript code as a string, returned in its output
3. Function block → receives the generated code string and executes it against the input data
4. Result → returned to the next block, structured and ready for use

This turns the Function block into an execution engine for AI-generated code — a lightweight version of a code interpreter, operating inside your workflow DAG with full access to upstream data.

A Real End-to-End Example: Invoice Processing

Here is how a complete workflow uses the Function block in production:

1. Webhook trigger — receives an invoice PDF from a document management system
2. AWS Textract block — extracts raw text and table data from the PDF
3. Function block (JavaScript) — parses the extracted tables, cleans amounts, calculates totals and tax, returns a structured invoice object
4. Condition block — routes based on total amount: under threshold → auto-approve, over threshold → human review
5. Google Sheets block — writes the structured invoice data to the accounting spreadsheet
6. Slack block — posts a summary with the total and approval status

The Function block is the step that transforms messy Textract output into a clean, typed object that every downstream block can use without guesswork.

Conclusion

The AACFlow Function block fills the space between "there's a connector for that" and "I need to write an application." It is not a replacement for dedicated integrations — it is the escape hatch that makes every workflow completable, regardless of what the real world throws at it.

When you need to apply custom business logic, parse a proprietary format, aggregate data across multiple inputs, or call an API that no one has built a connector for yet — drop in a Function block, write a few lines of JavaScript or Python, and keep building.