DEV Community: The Unmeshed Team

Why Do Scheduled Jobs Always Fail at the Worst Time?

The Unmeshed Team — Tue, 14 Jul 2026 06:06:00 +0000

Automating Complex Workflows with Scheduled Job

Unmeshed is designed to handle scheduled jobs and batch tasks with ease. It supports complex workflows and executes them with precision, whether you're running them every minute, once a day, once a year or at custom-defined intervals.

There are countless use cases require running a process on a regular schedule, such as generating monthly budget reports or performing hourly inventory checks. Unmeshed enables this with full support for cron expressions, giving you flexibility and control over your scheduling needs.

Setting Up Your Schedule in Unmeshed

The Unmeshed UI makes it easy to configure and manage schedules with full visibility. You can select your preferred time zone, choose a start time (immediately or at a future date) and toggle the schedule on or off.

Another key scheduling feature is the overlap policy. If you have long-running jobs and don't want a new run to start while the last one is still going, simply enable "Do not allow overlap." This ensures only one instance runs at a time, preventing data conflicts and resource contention.

Once the schedule is live, your process will trigger automatically based on your cron expression. You can monitor future runs and view execution history directly from the Schedules tab.

Cron Expressions

A cron expression is a simple string format used to define recurring schedules. Unlike interval-based triggers, cron schedules follow a fixed time pattern and do not consider when the last execution finished. This makes them ideal for use cases that require precise timing such as overnight batch jobs, database maintenance, or scheduled report generation.

Unmeshed supports Unix-cron, which includes five fields. A process is triggered whenever the current time matches the pattern defined by the cron expression. You can write your own cron expressions or use tools like crontab.co to generate them easily and paste them into the Unmeshed UI. Unlike interval-based scheduling, cron jobs do not depend on when the last execution finished and make them ideal for precise timing (e.g., 10:00 PM sharp for batch jobs).

* * * * *
| | | | |
| | | | └── day of the week (0–6, starting from Sunday)
| | | └──── month (1–12)
| | └────── day of the month (1–31)
| └──────── hour (0–23)
└────────── minute (0–59)

For example, for a process to trigger every workday at 10 PM, you would use:

0 22 * * 1-5

Roughly read as: trigger at minute 0, hour 22, on days Monday through Friday. The asterisk (*) means that the field is unrestricted.

Why Scheduled Workflows Matter

There are countless real-world scenarios where running a process on a regular cadence is not just helpful, it's essential. For example:

Generating monthly budget reports
Performing hourly inventory evaluations
Running overnight database backups
Executing regular system maintenance and more

Unmeshed helps you automate all of these with durable orchestration capability and built-in scheduling features, all without extra scripting or glue code.

Please Stop Sending Secrets Like They're Normal JSON.

The Unmeshed Team — Mon, 13 Jul 2026 08:51:02 +0000

Secret Inputs When Invoking a Process via Webhook APIs

In orchestration use cases, it's important to pass sensitive or confidential inputs such as tokens, credentials or environment-specific parameters to a workflow securely. This document outlines how to pass such secret data when invoking a process using the Webhook API.

When invoking a workflow process via Webhook API, secret can be securely included in the request body ensuring that they are not logged or exposed in plain input/output traces. It must only be accessible within the context of the invoked process.

Create Webhooks and Associating Process

Process Definition

Webhook Definition

API Invocation Example

Here is a sample curl request used to invoke a workflow using the Webhook API, while securely passing secret inputs.

To trigger a workflow in Unmeshed using the Webhook API, you can send a simple POST request with your input data in JSON format. In the example above, the workflow is invoked asynchronously using a secure URL that uniquely identifies the workflow.

Along with regular inputs like "key1": "value1", you can safely pass sensitive data using the _secretStatePut field, which ensures that secrets such as API keys or credentials are handled securely within the workflow.

What is `_secretStatePut`?

The _secretStatePut object allows user to provide inputs that are treated as secrets by the Unmeshed platform:

Not visible in logs or process summaries unless exposed in step's output or in logs of steps.
Not returned in API responses.
Accessible only within the running workflow's secured execution context.

Ideal for passing things like:

Access tokens
Encrypted configurations
Internal system credentials

You can use this feature for a variety of secure automation scenarios, such as triggering a deployment pipeline with environment-specific credentials, kicking off a data ingestion job that requires access to protected APIs. This lets you run powerful, event-driven automation without exposing sensitive information in your request payload.

Why Do Batch Jobs Still Take All Night?

The Unmeshed Team — Fri, 10 Jul 2026 10:28:37 +0000

Batch Job Automation with Built-In Job Scheduler

Handling batch jobs are essential in everything from regular data processing and report generation to syncing systems overnight. These jobs often involve predefined sets of steps that need to run at triggered times, and they're expected to do so without manual intervention. Unmeshed makes this easy. In this post, we demonstrate how to automate a complex batch process using the Unmeshed Scheduler.

Use Case: Automating Daily API Aggregation Jobs

Let's say your system needs to collect data from 25 different APIs every night, to process the responses, and later store the results for further reporting. This is a classic complex batch job made up of multiple steps, and it also running in parallel and triggered regularly. Here's how you can build and automate this job in Unmeshed.

Step 1: Define the Process

In Unmeshed, start by creating a new process definition. Then name it something like daily_api_aggregation.

Inside the process, use a Parallel task block to handle multiple API calls at once. We'll start with 5 HTTP steps inside the parallel block, with each calling a different endpoint.

To simulate a more complex job, duplicate the block multiple times. In this case, we duplicated it 5 times, resulting in 25 parallel HTTP steps.

This setup represents a realistic scenario where multiple independent tasks, such as fetching data from different sources, can run simultaneously for efficiency.

Step 2: Test the Performance

Once your workflow is built, you can run a quick test inside Unmeshed.

In our example, the process executed all 25 HTTP steps in under 100 milliseconds.

That's the kind of high-performance orchestration Unmeshed delivers.

Step 3: Schedule the Workflow

Now that your process works as expected, it's time to schedule it.

Unmeshed supports cron expressions. It delivers time-control precision on workflow, whether it's every hour, every Monday at 2 AM, or the first day of every month.

You can create a new schedule in the Unmeshed UI.

Another scheduler feature is the Overlap Policy, which prevents new jobs from starting if the previous one is still running.

If your batch process sometimes takes longer than expected, setting Do Not Allow Overlap ensures that jobs won't run in parallel unintentionally, preventing data conflicts and system strain.

Step 4: Watch It Run

Once saved, Unmeshed takes care of the rest.

In our demo, the job is triggered accurately, ran all 25 steps, and completed in just 55 milliseconds.

You can view all scheduled executions directly in the UI, giving you complete visibility and confidence.

Final Thoughts

Why Are We Still Downloading Files from SharePoint by Hand?

The Unmeshed Team — Thu, 09 Jul 2026 08:21:14 +0000

Integrating Microsoft SharePoint into the Unmeshed Platform

Microsoft SharePoint is everywhere in the enterprise world. From document management to internal collaboration, it plays a central role in business operations. But when it comes to building durable and scalable automation, SharePoint often feels... limited.

Unmeshed now includes native Microsoft SharePoint integration, making it easy to connect your SharePoint sites directly to automated workflows.

Whether you're building AI-powered document processing, approval workflows, or enterprise integrations, SharePoint is now part of your orchestration platform.

What You Can Do

1. Trigger workflows when new files are uploaded

When a user uploads a PDF or document to SharePoint, automatically start a workflow.

For example:

Extract data using AI
Classify documents
Store results in your database
Notify downstream systems

2. React to spreadsheet changes

Automatically detect updates to shared Excel files and sync the latest data with your database, CRM, or data warehouse.

No manual exports required.

3. Monitor file changes for audits

Schedule workflows that monitor SharePoint sites and generate reports of file activity.

Perfect for:

Security teams
Compliance reporting
Audit trails

4. Upload generated files back to SharePoint

Generate reports, invoices, exports, or PDFs inside Unmeshed and automatically publish them to the correct SharePoint folder.

5. Build your own SharePoint experience

Create custom APIs and user interfaces that browse SharePoint files without relying on the default SharePoint UI.

How It Works

Getting started takes only a few steps.

Connect your SharePoint account.
Map your SharePoint sites or folders.
Build workflows visually in the Unmeshed Flow Builder.

That's it.

You can now trigger workflows from SharePoint events or interact with SharePoint directly as part of larger business processes.

Why This Matters

Most organizations already use SharePoint to store documents.

The challenge isn't storing files.

It's everything that happens after a file is uploaded.

Approvals.

AI document extraction.

Notifications.

Database updates.

Moving files between teams.

With native SharePoint integration, these processes become part of one automated workflow instead of a collection of disconnected manual tasks.

Final Thoughts

SharePoint is a great place to store documents.

Now it can also become the starting point for durable, scalable workflow automation.

If your business relies on SharePoint, you can now connect it directly to Unmeshed and automate everything that happens after a document lands in a folder.

Cron Is Great... Until Your Business Gets Involved

The Unmeshed Team — Wed, 08 Jul 2026 11:47:57 +0000

Introduction

Workflow automation is a critical component of many business operations, handling tasks that require minimal human involvement. From generating financial reports and running overnight data jobs to performing system checks during maintenance windows, automation ensures these processes run efficiently and reliably.

These processes often rely on recurring execution, traditionally handled with cron expressions. While cron is effective for fixed intervals, it quickly becomes limiting when workflows need to align with real-world business calendars.

Unmeshed already offers robust cron-based scheduling for repeatable jobs, such as every hour or every day at 5 AM. But for more complex real-world scenarios, we introduced Calendar Scheduling. This feature lets you define custom calendars that act as intelligent filters, ensuring workflows run only on specific and valid days. You can also combine calendars, dynamically generate schedules, and control how jobs respond to skipped or excluded dates.

Supported Calendar Types in Unmeshed

Unmeshed supports four calendar types, each built for different scheduling needs:

List of Dates Calendar
Code Calendar
Derived Calendar
Reschedule Calendar

1. List of Dates Calendar

The List of Dates Calendar allows users to manually select execution dates through the UI.

Features

Define a date range and select individual days using a visual calendar.
Quickly select common patterns such as:
- Weekends
- Weekdays
- Specific weekdays (for example, every Monday)
Switch between Calendar View and List View to manage selected dates.

Use Cases

Non-technical users who prefer visual scheduling.
Fixed schedules such as monthly reviews or quarterly tasks.

2. Code Calendar

The Code Calendar enables developers to generate execution dates programmatically.

Features

Write custom logic to generate valid execution dates.
Use built-in templates to get started quickly.
Ideal for advanced scheduling scenarios such as:
- Every third Friday of the month
- First working day after a public holiday

Use Cases

Logic-driven scheduling.
Business rules that depend on application data.

3. Derived Calendar

The Derived Calendar combines two existing calendars using set operations.

Supported Operations

UNION — Combines all dates from both calendars.
INTERSECTION — Includes only dates present in both calendars.
DIFFERENCE — Includes dates from the source calendar that are not in the target calendar.
SYMMETRIC DIFFERENCE — Includes dates unique to either calendar.

Key Notes

Derived calendars cannot be edited manually.
Dates are automatically computed from the selected calendars and operation.
Preview the generated schedule before saving.

Use Cases

Combining multiple scheduling rules.
Excluding holidays from business-day calendars.

4. Reschedule Calendar

The Reschedule Calendar handles situations where scheduled executions need to be postponed instead of skipped.

Features

Skip execution on selected dates, such as holidays or maintenance windows.
Automatically reschedule skipped jobs after a configurable delay.
Fine-grained control over exception handling.

Use Cases

Holiday scheduling.
Planned maintenance windows.
Blackout periods.
Postponing jobs without cancelling them.

Using Calendars in the Job Scheduler

Calendars can be attached to schedules to control when jobs are allowed to run.

Each schedule can define either:

A CRON expression, or
A fixed execution time (for example, 9:00 AM)

When a calendar is associated with a schedule:

The calendar acts as a filter for eligible execution dates.
Jobs run only on dates included in the calendar at the configured time.

Note: Every calendar includes a preview of future execution dates, making it easy to validate schedules before deployment and avoid unexpected behavior.

Final Thoughts

Calendar Scheduling gives you fine-grained control over workflow execution by letting calendars filter your schedules.

Instead of forcing business rules into increasingly complex cron expressions, you can define calendars that reflect how your business actually operates.

If your workflows depend on holidays, business days, maintenance windows, or custom scheduling rules, calendar-based scheduling provides a much cleaner and more maintainable solution.

Why Wait Steps Behave Differently Inside While Loops

The Unmeshed Team — Tue, 07 Jul 2026 10:02:14 +0000

Using Wait Steps in Unmeshed: Handling Delays Inside While Loops

Waiting—whether for a webhook, a human approval, or simply a fixed pause—shows up in almost every orchestration scenario. In Unmeshed, you model these pauses with the Wait step, which accepts a JavaScript function that returns a Unix epoch timestamp (waitUntil) indicating when the step should complete.

Most of the time that's all you need. But as soon as you nest a Wait step inside a While loop, an easy-to-miss nuance can trip you up and make the wait look "broken." This post explains that behavior and shows a clean pattern for making loops and waits play nicely together.

Recap: How a Wait Step Works

When the Wait step starts, Unmeshed passes the step's execution context to your JavaScript function. A common implementation adds a fixed offset to the step's start time:

(steps, context) => {
  const startDate = new Date(steps.__self.start); // epoch millis when the step first began

  return {
    waitUntil: startDate.getTime() + 3_000, // wait 3 seconds
  };
};

steps.__self.start never changes for that step instance, so the first time through everything is perfect: the engine sleeps for three seconds and continues.

The Gotcha: Wait Inside While

A While step re-executes its inner graph as long as its condition remains true. Each inner step (including Wait) keeps its original start timestamp across iterations. That means:

Iteration 0 – Wait schedules start + 3,000 ms and pauses. ✅
Iteration 1 – The same Wait step runs again, but start is still the original value. Because that timestamp is already in the past, Unmeshed sees that waitUntil is satisfied and continues immediately. ⚠️

From the outside it looks like the engine ignored your wait—but it's really doing exactly what you asked.

A Robust Pattern: Per-Iteration Timestamps

The fix is to track a separate target time for every loop iteration. The snippet below pushes a new timestamp into an iterations array the first time each iteration executes, then reuses it on retries, restarts, or subsequent checks.

(steps, context) => {
  // Existing array (or []) pulled from the step's previous output
  const iterations = steps.__self.output.result?.iterations || [];
  const currentIter = steps.loop.output.iteration;

  // If we haven't stored a target time for this iteration yet, compute & save one
  if (iterations.length <= currentIter) {
    iterations.push(Date.now() + 3_000); // wait 3 seconds from *now*
  }

  return {
    waitUntil: iterations[currentIter],
    iterations, // persist the array for next pass
    loop: currentIter, // optional: surface the index for debugging
  };
};

Why This Works

Idempotent and restart-safe. If the engine restarts mid-wait, the stored timestamp is still there.
True per-iteration delay. Each loop cycle gets a fresh waitUntil computed relative to when that cycle began—not when the Wait step was first created.

Alternative Approaches

Approach	When to Use
Context-based key (for example, storing `waitUntil` in `processContext`)	Useful when multiple steps need to reference a shared schedule.
Dynamic While condition (moving the timer logic into the While condition itself)	Handy for simple polling loops where you can express "stop when 3 seconds have passed" directly.
Separate Wait step outside While	Best when you only need one delay before the loop begins.

Best Practices Checklist

✅ Treat Wait steps like any other stateful computation—make them idempotent and restart-safe.
✅ When looping, compute targets relative to now, not to the original start time.
✅ Always surface debugging information (such as the current iteration index) in the step output. It makes diagnosing timing issues much easier.
❌ A Wait step inside a loop does not behave like sleep() in synchronous code. Remember that the orchestration engine re-evaluates the same node instance on every iteration.

How to Build a Scalable Fraud Detection Workflow

The Unmeshed Team — Mon, 06 Jul 2026 10:03:33 +0000

The Growing Cost of Fraud

Fraudsters never stop innovating. From synthetic identities to deepfake onboarding, every year brings new tricks to exploit existing systems. The burden of catching fraud in real time falls directly on businesses and the cost of letting it slip through the cracks can be devastating.

According to Fortune Business Insights the global fraud detection and prevention market was valued at $52.82 billion in 2024 and is projected to exceed $246 billion by 2032. It reflects how serious and expensive the problem has become. Despite this, many organizations are still stuck with manual reviews and disconnected APIs, burning through budgets on processes that software could automate in seconds.

From Chaos to Clarity: How Unmeshed Streamlines Fraud Detection Pipelines

Use Case: Onboarding a New Customer via Digital Banking Platform

Meet Alice. She wants to open a digital bank account. Here's how Unmeshed orchestrates the onboarding pipeline to keep Alice and the bank safe:

A flow chart demonstrates how the workflow runs seamlessly in Unmeshed:

Workflow in One Glance

name: fraud_detection_pipeline

steps:
  - HTTP:   # Identity check
      id: kyc_check
      url: https://kyc.example.com/check
      body:
        userId: "{{ inputs.userId }}"

  - HTTP:   # Risk scoring
      id: risk_score
      url: https://risk.example.com/score
      body:
        transactionId: "{{ inputs.transactionId }}"
        kyc: "{{ steps.kyc_check.response.body }}"

  - DECISIONTABLE:   # Rules
      id: fraud_rules
      rules:
        - when:
            score: "<600"
          then:
            outcome: "BLOCK"
        - when:
            score: "<750"
          then:
            outcome: "REVIEW"
        - default:
            outcome: "APPROVE"

  - SWITCHCASE:   # Routing
      switch: "{{ steps.fraud_rules.outcome }}"
      cases:
        BLOCK:
          - HTTP:
              url: https://transactions/block
        REVIEW:
          - HTTP:
              url: https://review-queue/enqueue
        APPROVE:
          - HTTP:
              url: https://transactions/approve

Unmeshed manages the entire flow of API calls during digital banking onboarding, helping banks cut down on costly developer hours and avoid endless maintenance of fragile scripts, effectively freeing up budget for innovation.

Why Orchestration Saves Money

Instead of throwing more engineers or analysts at the problem, Unmeshed connects all the moving parts into single and automated flow. That shift saves money in three big ways:

1. Less Manual Review

Most fraud teams spend hours chasing false positives. Incorporating orchestration automates auto-approves on low-risk transaction; for high-risk case it can be blocked instantly. Human task is required only when the rules say, "required further review".

2. Eliminate Fragile Scripts to Maintain

Without orchestration, developer needs to spend substantial time and resources to fix broken script that stitch every API or data source, silently draining budgets and eating up developer’s time. Unmeshed handles the integrations automatically, freeing developers to focus on core work.

3. Predictable Cost at Any Scale

While it is not possible to fully eliminate fraudulent activities, Unmeshed handles millions of processes at fixed rate only.

Conclusion: Unmeshed Complements Fraud Detection Process Using Orchestration Platform

Fraud detection is complex and can’t be stitched together with broken scripts and siloed tools anymore. Unmeshed connects all the APIs and services into one seamless pipeline, so processes flow with little human intervention or brittle scripts.

Banks today spend millions on fraud analysts chasing false positives. With Unmeshed, one mid-market bank automated 95% of checks, cutting review workload by half.

Ready to see how Unmeshed can simplify your fraud workflows and save money? Book a demo today.

How Unmeshed Helped Modernize Logistics Software at Scale

The Unmeshed Team — Fri, 03 Jul 2026 11:54:30 +0000

Optimizing Logistics Software with Unmeshed

Learn how Unmeshed orchestration transforms logistics operations through automation of resilient and durable business processes.

Background

A leading logistics enterprise operating across North America with businesses ranging from freight brokers to carriers to customer handling through a digital freight platform. As global supply chains evolve and real time observability becomes a competitive necessity, the enterprise set out to modernize its operation to deliver faster and more transparent logistics experiences.

Dilemma

With freight volumes surging and new partner systems being added, the enterprise’s logistics stack had grown and becoming fragmented, forcing developers to stitch brittle scripts which hold systems together. Despite their best effort, substantial number of human hours are deployed to handle manual coordination between tools.

“Every day, our teams were switching between systems for pricing, tracking, billing, and communication. It wasn’t about lack of technology, rather it was about lack of connection,” explained technical team.

Solution

“Then we found Unmeshed. It provides orchestration and workflow automation in a low-code environment and still able to code complex logic and custom integrations, we could do everything we wanted in one unified platform,” said the technical team.

“Once we onboarded with Unmeshed, we were able to create logistics workflows and identified more use cases across other teams or processes. Once the workflow process is fully built in the orchestration platform, those modules can be plugged in anywhere within our workflow.”

The core business on any logistics company relies heavily on speed and efficiency, prompting the team to adopt CI/CD approach powered by Unmeshed. Unmeshed introduces a version-controlled orchestration environment to build durable APIs that run at scale. Unit test and integration test are part of the orchestration components ensuring rapid iteration and reliability across their supply chain operations.

“Unmeshed helped us design an end-to-end orchestration lifecycle,” said the team member overseeing implementation. “The workflows cover key logistics processes such as freight quoting, billing, invoice reconciliation, delivery exception handling and more. Recently, we’ve begun integrating AI-driven decision logic into workflow, to automatically flag anomalies, predict delivery delays and optimize route selections in real time. These reusable and intelligent workflows now serve as foundational building blocks to accelerate future integrations and significantly reduce engineering overhead across the organization.”

Impact

The results were transformative.

According to a study published in the International Journal for Multidisciplinary Research (IJFMR) by Pankaj Singhal (2024), enterprises implementing robust orchestration workflows experience a 47% reduction in service integration failures, leading to greater reliability and fewer disruptions across connected systems.

They also report a 35% improvement in resource utilization, as automation eliminates redundant tasks and allows teams to focus on higher-value engineering work. Furthermore, orchestration enables 62% faster deployment cycles without increasing infrastructure complexity. Together, these gains demonstrate how intelligent orchestration with Unmeshed can transform logistics operations into scalable and resilient workflow.

By leveraging Unmeshed orchestration, the logistics enterprise achieved similar operational gains. Unmeshed reduce integration friction to improve efficiency across carrier and shipment workflows, deliver real-time visibility across the logistics chain.

Next Step

Schedule a Consultation with Unmeshed to streamline your TMS, CRM and carrier systems into resilient automation layer that drives scale and ensure compliance, together with real-time intelligence across your supply chain.

Happy Orchestrating.

The Trade-Offs of AWS Step Functions (and Why Some Teams Move Beyond It)

The Unmeshed Team — Wed, 01 Jul 2026 11:05:02 +0000

As enterprises scale, AWS Step Functions is a popular choice to automate distributed workflows, all within AWS ecosystem. But many teams face recurring challenges as they scale, challenges that limit flexibility. In this blog, we will highlight those challenges and to show you that Unmeshed could be the practical and modern solutions for today’s API-driven and AI-powered environment.

Challenge 1: Cost

When workflows volumes grow into the millions, Step Functions quickly become expensive and operationally heavy due to per-state billing and limited scaling flexibility, whereas Unmeshed offers fixed price, eliminating per-state billing entirely. It runs orchestration directly on lightweight infrastructure cutting both compute and operational costs. We offer massive saving as compared to Step Functions. If you want to know how much your team could save annually, contact us.

Challenge 2: Tight AWS Lock-In

Locked into to one ecosystem? Facing downtime from a regional outage? That’s the reality with AWS Step Functions with everything depends on AWS-managed services. Unmeshed breaks that boundary, offering multi-cloud by design and running seamlessly across AWS, Azure, GCP or even on-prem environments. This ensures your workflows keep running even when a region or provider experiences downtime. Being flexible is critical for enterprise that demand resilience and control.

Challenge 3: User/Developer-First Experience

Unlike AWS Step Functions which require developers to write complex JSON definitions, Unmeshed built drag-and-drop workflow builder, YAML-based definitions, real-time debugging, tracing and more. New features are continuously added and updated to ensure users and developers spend less time to code and more time on business logic.

Challenge 4: Not A Real-Time, Not An API-Driven Orchestration

AWS Step Functions does not natively support true real-time and API-driven orchestration the way Unmeshed does. For more clarity, we list down some pain points from AWS Step Functions itself:

High Latency per Step - Each state transition in Step Functions adds measurable delay; on real-time or API-driven use cases such as chat or AI agent response come with high level of delay.
Missing on Synchronous Flow - Step Functions are built for event-driven and developer must bolt on API Gateway or Lambda wrappers to simulate a real-time flow, causing developers spending more time to monitor, instead of building features.
Limited Observability - CloudWatch logs is designed to observe execution data after completion, developers can’t see step progress, partial outputs or triggers as they happen.

Unmeshed solves this with built-in real-time orchestration with zero wait between steps. It provides unified support for both synchronous (request-response) and asynchronous (background) processes in one platform. Developers get to watch the live tracing and instant feedback loops with visual builder. Since it’s fully cloud-agnostic, it runs anywhere without dependency on AWS infrastructure.

Why Are Teams Moving to Unmeshed?

Unmeshed is built to modernize orchestration platform. By removing dependencies on AWS-specific services, Unmeshed delivers faster startup time, decreasing latency and greater resilience. If your team is scaling workflows across clouds or modernizing legacy orchestration, there’s never been a better time to move to Unmeshed.

Large Files Don't Belong in Your Workflow State

The Unmeshed Team — Mon, 29 Jun 2026 09:51:15 +0000

Introduction

Large payloads do not always belong inside request bodies, step outputs, or execution state. When a process needs to work with Excel files, CSV exports, reports, or other bulky documents, it is usually better to store the file temporarily and let the workflow operate on the file path instead of pushing the full payload through every step.

This approach keeps the process cleaner, reduces unnecessary payload movement, and makes file-heavy automation easier to manage.

In this post, we will walk through an Unmeshed process that:

Downloads a file from a remote URL into mounted Unmeshed storage
Reads and processes the file inside an Unmeshed Python Step
Deletes the file after processing is complete

Why Handle Large Payloads This Way

For small JSON inputs, passing data directly between steps is simple. For large files, that pattern becomes inefficient.

Common issues with large inline payloads include:

bloated request or response sizes
slower step-to-step data movement
harder debugging when outputs become too large
unnecessary memory pressure during execution

Using mounted storage gives you a better pattern:

the file is downloaded once
subsequent steps read it from disk
only useful metadata and results are returned in step output
the temporary file can be removed at the end of the process

In Unmeshed, /app/files is mounted to Unmeshed file storage. That makes it the correct location for temporary file-based processing inside a process execution.

You can verify uploaded files from FileBrowser under Data and Assets in Unmeshed. This is where files written to mounted storage can be viewed after they are uploaded by a process step.

The image above shows File Browser under Data & Assets, where you can inspect files that have been uploaded to Unmeshed storage.

Use Case

Assume an upstream system provides an Excel file through a signed URL or file endpoint. The process needs to:

fetch the file
parse the spreadsheet
generate a quick summary
clean up the temporary copy

That is exactly what the large_payload_handling process does.

Process Overview

The process contains three Unmeshed Python Steps:

temp_upload_to_unmeshed_storage
read_records_and_process
delete_file

Step 1: Download the File in an Unmeshed Python Step

The first Unmeshed Python Step downloads a remote Excel file and stores it under /app/files/myfiles/customFile.xlsx.

This matters because /app/files is mounted to Unmeshed storage. If you save the file elsewhere, the next step may not be able to access it in the same expected way.

import os
import requests

def main(steps, context):
    file_url = "https://testing.s3.amazonaws.com/abcd/pqr/1234/myfile.xlsx"

    # /app/files is mounted to Unmeshed file storage
    file_path = "/app/files/myfiles/customFile.xlsx"

    os.makedirs(os.path.dirname(file_path), exist_ok=True)

    try:
        with requests.get(file_url, stream=True, timeout=60) as response:
            response.raise_for_status()

            with open(file_path, "wb") as f:
                for chunk in response.iter_content(chunk_size=8192):
                    if chunk:
                        f.write(chunk)

        return {
            "statusMessage": f"File downloaded and saved to {file_path}",
            "isSuccessful": True
        }

    except Exception as e:
        return {
            "statusMessage": f"Download failed: {str(e)}",
            "isSuccessful": False
        }

What this Unmeshed Python Step does

downloads the file as a stream instead of loading it fully into memory
writes the content in chunks
creates the target directory if it does not already exist
returns a status message for execution visibility

Streaming is important here because it is a safer pattern for larger files.

Step 2: Read and Process the File in an Unmeshed Python Step

Once the file is available in storage, the second Unmeshed Python Step opens it with pandas and performs sample processing.

import pandas as pd

def main(steps, context):
    file_to_process = "/app/files/myfiles/customFile.xlsx"

    try:
        df = pd.read_excel(file_to_process)

        row_count = len(df)
        column_count = len(df.columns)
        columns = list(df.columns)

        df = df.fillna("N/A")

        numeric_summary = {}
        numeric_cols = df.select_dtypes(include=["number"]).columns
        for col in numeric_cols:
            numeric_summary[col] = df[col].sum()

        preview_data = df.head(5).to_dict(orient="records")

        return {
            "rowCount": row_count,
            "columnCount": column_count,
            "columns": columns,
            "numericSummary": numeric_summary,
            "preview": preview_data
        }

    except Exception as e:
        return {
            "statusMessage": f"Error processing file: {str(e)}",
            "isSuccessful": False
        }

What this Unmeshed Python Step returns

Instead of returning the full spreadsheet content, this step returns a compact and useful summary:

total row count
total column count
list of columns
numeric column summary
preview of the first five rows

This is a much better output contract than passing the entire file content through the workflow state.

Step 3: Delete the Temporary File in an Unmeshed Python Step

After processing is complete, the last Unmeshed Python Step removes the file from storage.

import os

def main(steps, context):
    file_path = "/app/files/myfiles/customFile.xlsx"

    try:
        if os.path.exists(file_path):
            os.remove(file_path)
            message = "File deleted successfully"
        else:
            message = "File does not exist"

        return {
            "statusMessage": message,
            "isSuccessful": True
        }

    except Exception as e:
        return {
            "statusMessage": str(e),
            "isSuccessful": False
        }

Cleaning up temporary files is a good operational habit. It helps prevent storage buildup when the process runs repeatedly.

End-to-End Flow

The full execution looks like this:

Fetch the Excel file from a remote location
Save it to /app/files
Open it in an Unmeshed Python Step
Extract useful summary data
Delete the temporary file

This pattern is simple, reliable, and practical for file-based workflows.

Process Definition Summary

Below is the same process expressed in documentation format for easy reference.

Process Metadata

Name: large_payload_handling
Version: 1
Namespace: default
Type: API_ORCHESTRATION

Step Definitions

1. `temp_upload_to_unmeshed_storage`

Type: PYTHON
Purpose: An Unmeshed Python Step that downloads a remote Excel file and stores it in Unmeshed-mounted storage.
Input source: Remote file URL
Output: Status of file download

2. `read_records_and_process`

Type: PYTHON
Purpose: An Unmeshed Python Step that reads the Excel file and generates a compact summary.
Input source: File stored at /app/files/myfiles/customFile.xlsx
Output: Row count, column count, column names, numeric summary, and preview rows

3. `delete_file`

Type: PYTHON
Purpose: An Unmeshed Python Step that deletes the temporary file after processing.
Input source: File path in mounted storage
Output: Deletion status

Full Process Definition

In this process definition, the Python code is authored directly inside each Unmeshed PYTHON step.

{
  "orgId": 1,
  "namespace": "default",
  "name": "large_payload_handling",
  "version": 1,
  "type": "API_ORCHESTRATION",
  "steps": [
    {
      "name": "temp_upload_to_unmeshed_storage",
      "type": "PYTHON",
      "ref": "temp_upload_to_unmeshed_storage",
      "input": {
        "script": "Python code inside the Unmeshed step downloads the file from a remote URL and stores it under /app/files/myfiles/customFile.xlsx"
      }
    },
    {
      "name": "read_records_and_process",
      "type": "PYTHON",
      "ref": "read_records_and_process",
      "input": {
        "script": "Python code inside the Unmeshed step reads the Excel file using pandas, computes summary information, and returns a compact preview"
      }
    },
    {
      "name": "delete_file",
      "type": "PYTHON",
      "ref": "delete_file",
      "input": {
        "script": "Python code inside the Unmeshed step deletes the temporary file from mounted Unmeshed storage"
      }
    }
  ]
}

Best Practices for Large Payload Workflows

store large files in mounted storage instead of workflow state
stream downloads when possible
return summaries, not full file contents
keep file paths predictable across steps
always clean up temporary files after processing

If your workflow handles CSV files, PDFs, reports, or generated documents, this same pattern works well with only minor changes to the processing step.

Final Thoughts

Large payload handling in Unmeshed is straightforward when you treat the file as a temporary resource rather than as step-to-step inline data.

By combining mounted storage with Unmeshed Python Steps, you can build workflows that download, process, and clean up large files in a controlled and maintainable way.

Why Telecom Order Fulfillment Becomes a Workflow Problem

The Unmeshed Team — Thu, 25 Jun 2026 12:04:19 +0000

The telecom industry has some of the most complex and distributed systems out there. Over time, business logic gets stitched together in whatever way makes sense at the time. Some parts become event-driven through pub/sub, some stay as direct API calls and state gets tracked across different databases.

In a typical telecom environment, you are dealing with modern microservices, legacy OSS/BSS platforms, and third-party integrations. Each system owns a small part of the overall workflow. If you want a deeper dive into OSS/BSS fundamentals, Ericsson has a good reference.

This setup works when things are simple. But once workflows become long-running, stateful, and spread across many systems, it becomes harder to manage. Durability gets questionable and scaling gets harder. Soon enough, no one has a clear end-to-end picture.

Instead of getting into every telecom-specific detail, we will use an order fulfillment workflow to show how these pieces can be brought together into one coherent process. The goal is to show how Unmeshed can act as the orchestration layer that connects systems, keeping the workflow visible. While this example is based on telecom, the same business logic applies to any industry dealing with complex and distributed workflows.

System Requirements For Scalable Telecom Orchestration

For this kind of workflow, the system needs to remember where each order is and be able to resume after failures. It also needs to avoid duplicate execution and show the status (completed, pending or blocked).

With Unmeshed, independent steps like data fetches and validations can run in parallel. Teams can also build human-in-the-loop flows by pausing for approvals, routing tasks to the right people, and resuming the workflow without breaking the overall process. A mature orchestration platform should handle retries, timeouts, partial failures, and pause-and-resume behavior while preventing duplicate or conflicting execution through identifiers like order IDs.

As the workload scales, teams spend less time worrying about performance and SLAs while still supporting both API-driven and event-driven workflows. They should also retain a complete audit trail of every action and decision across the process.

Use Case: Designing an Order Fulfillment Workflow

Telecom order fulfillment appears simple on the surface. A user selects a plan and chooses a device and places an order. In practice this initiates a multi-stage workflow that spans customer systems network provisioning inventory management billing and external integrations. Each stage introduces its own challenges and processes can run into failures latency-related issues and data dependencies which makes the workflow both distributed and stateful.

Now there are a few ways you could build something like this.

One approach is chaining API calls together. It starts with the frontend calling one service which calls another which calls another. It is simple but once you introduce things like waiting for instance giving the buyer a 24-hour waiting period while the cart remains open it starts to become awkward and increases the risk of partial or full failures. Eventually it gets messy, the state gets scattered across services and it becomes harder to know what is actually going on.

Another approach is to rely heavily on event-driven systems where you publish events, let different services react and store state in databases.

This is more flexible and scalable but the downside is that your workflow logic is spread across multiple systems and teams. Because of the lack of visibility debugging becomes painful and something as simple as “where is this order stuck?” turns into a multi-hour investigation.

Workflow in Action - Inside Unmeshed Platform

Here, Unmeshed coordinates workflow, from the moment a user initiates an order. Instead of letting workflow logic live everywhere we model it as a Process Definition in Unmeshed. The first thing we do is wait for the cart to be finalized. This might sound trivial but it actually is not because we need to hold the state for potentially hours.

In this workflow we model this as a Wait step with a pause of up to 24 hours. At times updates like adding a phone or changing a plan come in via APIs and update the same workflow instance. If the user fails to complete the purchase the workflow is either closed or a reminder email is sent. This is noticeably hard to do cleanly with just APIs or pub/sub.

Once the user checks out that is where things get interesting.

Coordinate Parallel Work and Decision Table

At this point a sequential workflow is not the most practical method because it increases the latency of the workflow. We model this using the Parallel step in Unmeshed where multiple independent steps can run in parallel such as fetching product details validating the plan pulling user data and running a credit check. Based on the output of all those steps we need to decide what to do next. For example, does this order require manager approval? Instead of hardcoding this logic we push it into the Decision Table so business rules can evolve without rewriting code.

Once we know the approval level we bring in a Human-in-the-loop step. The workflow pauses and routes the task to the appropriate queue. If a manager cannot approve it they can escalate it to another approver and the workflow simply loops back and re-routes accordingly.

From Approval to Fulfillment

Now comes the non-trivial part of the entire workflow. We need the system to pause, resume and reroute without losing state or duplicating work. Once the approval is completed we move into fulfillment and this is where multiple backend systems come into play.

Reserve inventory for the phone
Create an order in a retail or fulfillment system
Notify the store
Update CRM and billing systems
Trigger network provisioning to activate the line

Each of these is modeled as an HTTP step or integration step in Unmeshed. Failures happen in the real world and anything that could potentially happen probably will at some point, but we will not spend too much time explaining all of them here.

Why Workflow Visibility Matters at Scale

At a small scale almost anything works. As you scale anything can happen and everything breaks in interesting ways. Workflows run for hours or days, systems go down, traffic spikes happen and requirements change mid-flight.

Without orchestration you usually end up handling retries, rollbacks and partial failures across multiple services yourself. With orchestration, all of these can be automated much more easily because they live in one place which is the workflow.

Visibility matters at this point because it stops you from making wild guesses about how the system failed and frantically trying to locate where it failed. Every time this workflow runs Unmeshed keeps a full execution history. So if a client calls and asks “What happened to my order?” we could literally pull up the workflow using an order ID and see:

Which steps ran
What data each step received
Where it failed if it failed
What decisions were made

That level of visibility is almost impossible when logic is spread across systems.

Bringing It Together

Telecom order fulfillment is not just about connecting systems. At some point, it becomes about coordinating what happens across them.

Once approvals, retries, failures, and long-running states come in, you need to know where the order is and what should happen next. That is the part orchestration helps with. Instead of spreading that logic across services, you keep the flow in one place and let each system do its own job.

If you have workflows like this, try modeling one in Unmeshed and see whether it feels cleaner.

Automating Lead Qualification Without Glue Code

The Unmeshed Team — Wed, 24 Jun 2026 10:08:44 +0000

Lead enrichment is a workflow problem

Most signup systems start simple and then gradually accumulate logic around them. First you save the lead. Then you enrich the company domain. Then you verify whether the address is personal, disposable, or worth following up. Then someone asks for a Slack alert for promising signups. Before long, that "small" backend feature is spread across API handlers, background jobs, retry scripts, and a few hard-to-trace conditionals.

That is exactly the kind of problem orchestration should own.

This workflow shows how to keep the entire signup qualification path in one Unmeshed process while using Supabase Postgres as the system of record. The flow validates the incoming lead, stores it immediately, enriches the email domain with Hunter, verifies the mailbox with Kickbox, classifies the lead, routes high-value signups to Slack, and writes the enrichment result back to the same user record.

What this workflow does

The process definition is named enrich_classify_and_route, and the shape is straightforward:

signup payload
  -> validate_input
  -> postgres_insert_user
  -> http_hunter_domain_search
  -> http_kickbox_verify
  -> classify_lead
  -> switch_lead_route
      -> slack_message_high_value | exit_skip_slack_low_value
  -> postgres_update_user_enrichment

The workflow follows a simple but important sequence:

The lead is written to Supabase before any external enrichment call runs.
Hunter and Kickbox add context without turning the initial signup into a brittle all-or-nothing transaction.
Slack only receives leads that pass the qualification rule.
Supabase is updated at the end so the source-of-truth record reflects the outcome of the workflow.

That sequencing is practical. If Hunter is slow or unavailable, you still have the signup stored safely. If Kickbox flags the email as free or disposable, the workflow records that information and exits the alerting path cleanly.

Step-by-step walkthrough

1. Validate and normalize the incoming lead

The first JavaScript step, validate_input, expects a payload with email and name. It trims the values, lowercases the email, confirms the format is valid, and extracts the domain. If the payload is malformed, the workflow fails immediately with a clear error instead of writing incomplete data downstream.

This is a small step, but it sets the tone for the whole process: every later step receives a predictable structure.

2. Insert the lead into Supabase

postgres_insert_user persists the lead with a simple SQL statement:

INSERT INTO users (email, full_name)
VALUES (:#email, :#full_name)
RETURNING email;

Unmeshed binds the validated values directly from validate_input, so the workflow writes a clean row before it asks any third-party service for more information. That design is useful in production because enrichment vendors can fail independently of your core signup path.

Supabase fits naturally here because, for this workflow, it is standard PostgreSQL. Unmeshed connects through the Postgres integration and treats the users table as the durable record of the lead.

3. Enrich the company context with Hunter

The http_hunter_domain_search step calls Hunter's combined find API using the saved email address:

https://api.hunter.io/v2/combined/find?email={{steps.postgres_insert_user.output.results[0].email}}&api_key={{secrets.hunter_io_api_key}}

This step is marked optional, which is a thoughtful choice. Company enrichment is valuable, but it should not prevent the workflow from completing. If Hunter returns company data, the workflow can use it. If not, the process can still continue with the best information it has.

4. Verify the mailbox with Kickbox

The http_kickbox_verify step checks the same email with Kickbox:

https://api.kickbox.com/v2/verify?email={{steps.postgres_insert_user.output.results[0].email}}&apikey={{secrets.kickbox_api_key}}

The important signal in this workflow is whether the address is free or disposable. That becomes the main input to qualification in the next step.

5. Classify the lead

classify_lead merges the outputs from validation, Hunter, and Kickbox into one normalized result object:

email
full_name
company
is_free_email
lead_type

The current implementation uses a simple rule: if Kickbox reports free === true, the lead is classified as low_value; otherwise it becomes high_value.

That is deliberately easy to understand and extend. Today, the workflow uses mailbox quality as the qualification gate. Tomorrow, the same step can incorporate company size, industry, geography, or CRM scoring without changing the outer structure of the process.

6. Route qualified leads to Slack

The switch_lead_route step checks classify_lead.output.result.lead_type.

high_value -> slack_message_high_value
low_value  -> exit_skip_slack_low_value

That keeps notification logic out of application code. Sales or operations teams can trust that only leads meeting the workflow rule are pushed into Slack, and the message already includes the details that matter: name, email, and company.

7. Update the user record with enrichment results

The final Postgres step writes the classification back to Supabase:

UPDATE users
SET
  company = :#company,
  is_free_email = :#is_free_email,
  lead_type = :#lead_type
WHERE email = :#email
RETURNING email;

This closes the loop neatly. The signup row starts with the basic identity fields, then the workflow appends the enrichment outcome once external checks are complete.

Why this design works well in practice

There are plenty of ways to assemble this with controllers, queue workers, and custom scripts. The problem is not whether that approach can work. It is how long it stays understandable.

With a single orchestration definition, teams get a few advantages immediately:

The full lifecycle of a lead is visible in one place.
Each step has explicit inputs, outputs, and execution history.
Secrets for Hunter and Kickbox stay in workflow-managed configuration.
Routing logic is easy to inspect and change without hunting through multiple services.
Database writes and notifications become part of one traceable process instead of separate concerns.

For teams running growth, onboarding, or outbound workflows, that visibility matters just as much as automation.

A few implementation details worth noticing

This workflow has several good design choices that are easy to miss on a first read:

This is the kind of workflow that tends to grow with a product. Once the basic pipeline is working, most teams add CRM sync, deduplication, account assignment, welcome-email branching, or human review. Starting with an orchestration makes those additions much easier to reason about.

Natural next extensions

The current version is already useful, but it is also a strong foundation for a more opinionated lead-ops pipeline. Common next steps include:

Add company-size or industry checks inside classify_lead for more granular scoring.
Write Hunter metadata such as domain confidence or organization details back to Supabase.
Push high-value leads into a CRM in parallel with the Slack alert.
Add retry policies or fallback behavior around third-party enrichment calls.
Store workflow outcomes in a separate audit table for reporting and sales analytics.

Because the workflow is already definition-driven, those changes stay additive instead of forcing a broader rewrite.

Final thoughts

The strongest part of this example is not that it uses Supabase, Hunter, Kickbox, or Slack. It is that the business process is explicit. A lead arrives, gets validated, gets stored, gets enriched, gets classified, and gets routed. Every step has a clear responsibility, and the resulting state is written back to the database your team already uses.

That is what good orchestration looks like in practice: less hidden glue code, fewer scattered decisions, and a cleaner path from signup to follow-up.

DEV Community: The Unmeshed Team

Why Do Scheduled Jobs Always Fail at the Worst Time?

Automating Complex Workflows with Scheduled Job

Setting Up Your Schedule in Unmeshed

Cron Expressions

Why Scheduled Workflows Matter

Please Stop Sending Secrets Like They're Normal JSON.

Secret Inputs When Invoking a Process via Webhook APIs

Create Webhooks and Associating Process

Process Definition

Webhook Definition

API Invocation Example

What is _secretStatePut?

Why Do Batch Jobs Still Take All Night?

Batch Job Automation with Built-In Job Scheduler

Use Case: Automating Daily API Aggregation Jobs

Step 1: Define the Process

Step 2: Test the Performance

Step 3: Schedule the Workflow

Step 4: Watch It Run

Final Thoughts

Why Are We Still Downloading Files from SharePoint by Hand?

Integrating Microsoft SharePoint into the Unmeshed Platform

What You Can Do

1. Trigger workflows when new files are uploaded

2. React to spreadsheet changes

3. Monitor file changes for audits

4. Upload generated files back to SharePoint

5. Build your own SharePoint experience

How It Works

Why This Matters

Final Thoughts

Cron Is Great... Until Your Business Gets Involved

Introduction

Supported Calendar Types in Unmeshed

1. List of Dates Calendar

Features

Use Cases

2. Code Calendar

Features

Use Cases

3. Derived Calendar

Supported Operations

Key Notes

Use Cases

4. Reschedule Calendar

Features

Use Cases

Using Calendars in the Job Scheduler

Final Thoughts

Why Wait Steps Behave Differently Inside While Loops

Using Wait Steps in Unmeshed: Handling Delays Inside While Loops

Recap: How a Wait Step Works

The Gotcha: Wait Inside While

A Robust Pattern: Per-Iteration Timestamps

Why This Works

Alternative Approaches

Best Practices Checklist

How to Build a Scalable Fraud Detection Workflow

The Growing Cost of Fraud

From Chaos to Clarity: How Unmeshed Streamlines Fraud Detection Pipelines

Use Case: Onboarding a New Customer via Digital Banking Platform

Workflow in One Glance

Why Orchestration Saves Money

1. Less Manual Review

2. Eliminate Fragile Scripts to Maintain

3. Predictable Cost at Any Scale

Conclusion: Unmeshed Complements Fraud Detection Process Using Orchestration Platform

How Unmeshed Helped Modernize Logistics Software at Scale

Optimizing Logistics Software with Unmeshed

Background

Dilemma

Solution

Impact

Next Step

The Trade-Offs of AWS Step Functions (and Why Some Teams Move Beyond It)

Challenge 1: Cost

Challenge 2: Tight AWS Lock-In

Challenge 3: User/Developer-First Experience

Challenge 4: Not A Real-Time, Not An API-Driven Orchestration

What is `_secretStatePut`?

1. `temp_upload_to_unmeshed_storage`

2. `read_records_and_process`

3. `delete_file`