Account Store vs Flow Store vs Memory Store in webMethods.io Integration

Overview :

webMethods.io Integration provides a cloud-based environment for building and managing integration workflows. As part of this platform, it offers various storage mechanisms to handle data securely and efficiently during workflow execution. The Account Store, Flow Store, and Memory Store each serve distinct purposes—ranging from securely managing credentials, storing persistent workflow data, to handling temporary in-memory values. Understanding the differences between these storage options is crucial for designing scalable, secure, and optimized integrations. This article explores each store’s role, scope, and best-use scenarios to help developers make informed decisions in their integration designs.

🔐 Account Store :

The Account Store in webMethods.io Integration allows you to save key-value pairs that are accessible across all projects and workflows in your tenant. This makes it easy to share common data like configuration values or credentials globally.

For example, imagine you have two projects: Default and Recipes. In the Default project, you create a workflow to store a key-value pair. Later, in the Recipes project, you can create another workflow that retrieves the same value—no extra setup needed. It’s a convenient way to keep shared data in one place and use it anywhere.

• Purpose: Stores connection details like usernames, passwords, API keys, OAuth tokens, etc.
• Scope: Globally available in the tenant – once created, any workflow or trigger in the project can use it.
• Persistence: Persistent – stays until you delete it.
• Example: You create an account for Salesforce with client ID and secret – you use that in multiple workflows in multiple projects needing Salesforce access.

🔄 Flow Store :

The Flow Store lets you save key-value pairs that are specific to a single workflow in webMethods.io Integration. This is useful when you want to store data that your workflow can use across different executions or resume later.

For example, you can save a value like a session ID or a user input in one workflow execution, and retrieve it in the next run of the same workflow using a unique key. The data stays saved until you delete or update it, making it perfect for use cases like pause-resume or temporary checkpoints.

• Purpose: Used to store data specific to a workflow’s execution or state.
• Scope: Workflow-level. The data is stored per flow instance, and you can fetch it using a unique key.
• Persistence: Persistent until you remove it or overwrite it.
• Example: In an order processing workflow, you can use Flow Store to track the status of each order. For example, store the order ID as the key and the current stage (like “Packed”) as the value. As updates come in, your workflow can fetch and update the status—keeping order progress in sync across multiple steps or events.

⚡ Memory Store :

The Memory Store is designed for short-term use within a single execution of a workflow. It allows you to store and reuse data only while the workflow is running.

For example, if you’re processing some data and need to reuse a value (like a counter or temporary result) in multiple steps of the same execution, you can store it in the Memory Store. Once the workflow completes, the data is cleared automatically. It’s ideal for handling intermediate values without making them permanent.

• Purpose: Temporarily stores data during a single execution of a workflow.
• Scope: Only valid during that execution.
• Persistence: Non-persistent – data is lost after the flow completes.
• Example: You’re doing calculations across multiple steps and want to hold intermediate values without exposing them.

🆚 Summary Table:

🗂️ Getting Started with Storage Options in webMethods.io Integration :

To explore how Account Store, Flow Store, and Memory Store work in webMethods.io Integration, follow the steps below to create a hands-on demo project.

🛠️ Step 1: Create Project and Workflow :

• Login to your webMethods.io Integration environment.
• Create a new project and name it StorageDemo.
• Inside this project, create a workflow named Storage.

• Click the settings icon of the workflow and create a parameter:

  • Name: tag

  • Value: MSP
    (This stands for Memory Store Put — we will change this value during testing to see how each storage option behaves)

🧱 Step 2: Design Your Workflow :

Design the workflow similar to the snapshot below . The key element is a Switch step that routes logic based on the value of the tag parameter.

Each switch case demonstrates a different storage action:

• Memory Store
• Flow Store
• Account Store

You’ll be able to observe how each type of storage behaves differently when you run the workflow with various parameters.

In this demo, we’ve not implemented the Get action for Account Store within the same workflow. However, you can:

• Create a separate workflow in the same project, or

• Create a new workflow in a different project,
  to retrieve the key "Hi" from Account Store — you’ll see the value "Bye" is returned globally across projects.

We’ve included the complete workflow code as a downloadable Git project at the end of this article. Simply import it into your tenant to explore and test it out yourself.

▶️ Step 3: Run the Workflow with Different Parameters :

Before each execution, change the workflow parameter tag to one of the values below and observe the logs in the Execution History. This will help you clearly understand how each storage option behaves.

✅ Summary :

By changing the tag parameter and observing the output in logs, you’ll get a clear picture of the differences between:

• Memory Store (temporary during workflow run)

• Flow Store (persisted per workflow)

• Account Store (global and cross-project)

Hope you found this article helpful! Click here to download the project files from GitHub.