Building a basic automated workflow

iWorkflow is an automation module within the iDMS that allows staff users to link a series of actions together, initiated by a trigger. Rather than manually running individual tasks one at a time, iWorkflow lets you define a sequence of steps that execute automatically -- whether on a schedule, through a webhook, or manually from the dashboard.

Workflows are especially valuable when you need to coordinate multiple iDMS operations that must run in order, or when those operations need to happen on a recurring basis without staff intervention. A workflow carries data between each action step, meaning the output of one action can feed directly into the next.

At its core, every iWorkflow is made up of two things:

• Trigger — What starts the workflow. This can be manual, scheduled (using a cron expression), webhook-based, or initiated by a change notification from iMIS.
• Actions — The steps the workflow takes once triggered. Actions can run iUpdate tasks, fetch IQA data, insert activities, make HTTP requests, execute JavaScript, upload files, and much more.

Workflows can be in one of three states:

• Active – Runs normally
• Disabled – Paused, editable, still counts toward licensing
• Archived – Inactive, not editable, does not count toward licensing

Building a workflow

This tutorial walks through a common scenario that many associations encounter: automatically updating member type based on renewal status.

Scenario: Each night, the association needs to find all members whose renewal date has passed and mark them as lapsed. Currently, staff run this iUpdate task manually, but the goal is to automate it so it runs every night at 11:00 p.m. without any manual effort.

This use case works for iWorkflow because it involves a recurring task that must run in a predictable sequence and on a fixed schedule. The workflow will use a scheduled trigger to fire nightly and an iDMS iUpdate action to apply the member type change across all qualifying records.

📘

NOTE

Before building this workflow, the iUpdate task itself must already be created and saved. iWorkflow does not create iUpdate tasks. It simply orchestrates the execution of tasks that already exist.

The following steps guide you through creating a basic automated workflow using the iWorkflow Wizard, which is the recommended starting point for common automation scenarios like scheduling iUpdate tasks.

Creating the workflow

To create the new workflow, do the following:

1. Log in to the Cloud Dashboard.

2. Go to iWorkflow > Dashboard.

   📘

   NOTE

   The iWorkflow Dashboard displays all existing workflow definitions. Each entry shows the workflow name, creation details, last modified information, and a visual summary of recent runs. Green bars indicate successful runs, red bars indicate failures, gray bars indicate cancelled workflows, and blue outlined bars show currently running workflows.

3. Click New, then choose From Wizard. The following options are available:

   • Schedule iUpdate Tasks — Run one or more iUpdate tasks in a scheduled sequence.
   • Export Data to URL — Pull IQA data and expose it at a public URL.
   • Schedule a Text Manager Campaign — Run a recurring text campaign on a schedule.

4. For this example, choose Schedule iUpdate Tasks.

5. Click Start.

6. Enter a descriptive Name, for example, Nightly Member Lapse Update.

7. Click Next.

8. Choose when the workflow should run. For this example (11:00 p.m.), enter 0 23 * * *.

   📘

   NOTE

   Workflow uses cron expressions to define schedule. If you are not familiar with cron syntax, click Build Schedule to use a guided builder that supports hourly, daily, weekly, monthly, and one-time run options. For more advanced cron expressions, see freeformatter.com.

9. Click Next.

10. Click the green plus button to add an iUpdate task to the workflow.

11. Use the dropdown to select the saved iUpdate task you want to run. In this case, the task that marks lapsed members.

    📘

    NOTE

    You can add multiple iUpdate tasks to a single workflow if needed. The tasks run sequentially, and the outcome of one task does not affect whether the next one runs. Each is an independent step, similar to how back-to-back nightly jobs work.

    ✅

    TIP

    The iUpdate task must already be saved before it can be added to a workflow. If you have not saved the task yet, go to iUpdate, configure your mappings, click Schedule as Task, and save it. You can also click + Add to New or Existing Schedule directly from iUpdate, which saves the task and opens iWorkflow automatically.

12. Click Next.

13. Review the workflow summary, which displays the trigger type, schedule, and the list of iUpdate actions. If everything looks correct, click Finish.

The workflow is now active. It will appear on the iWorkflow Dashboard with an Active status and will execute automatically the next time its scheduled trigger fires. To make any changes, use Editing a Workflow from the dashboard.

Testing a workflow: Best practices

Before relying on a workflow to run automatically against a full dataset, it is critical to test it thoroughly.

Review the following testing best practices.

Starting with a small dataset

Begin by running the underlying iUpdate task manually against a small, controlled subset of records before enabling the workflow. You can do this by temporarily adjusting the IQA query used by the iUpdate task to return only a handful of records. Ideally, you will test against accounts or records you can easily verify and revert. When scoping the test dataset, consider the following:

• Choose 3 to 10 records that represent the variety of conditions your task will encounter.
• Use test records or known accounts rather than real member data whenever possible.
• Make a note of the current values for the fields being updated so you can compare before and after.

Validating the data

After the workflow runs on your small dataset, verify that the results are what you expected before moving on. Validation is not just confirming the run completed. You must also check the actual data in iMIS.

Do the following to validate the data:

1. Open iMIS and navigate to the contact account pages that were included in your test run.
2. Confirm the updated fields reflect the correct new values (for example, member type now shows Lapsed).
3. Check for any records that should have been updated but were not, or records that were updated unexpectedly.
4. Review the workflow run log in iWorkflow (Dashboard > [Workflow] > View Runs) to check for any errors or warnings on individual actions.

If the results are not what you expected, review the IQA query feeding the iUpdate task, the field mappings, and the matching rules before proceeding.

Scaling up gradually

Once the small dataset validates successfully, expand the scope incrementally. Do not jump directly from 10 records to your full membership database. Instead, follow a tiered approach:

1. Expand to a medium dataset — perhaps 100 to 500 records — and run again.
2. Validate the results using the same approach as before.
3. If results are clean, expand further — 1,000 or more records.
4. Continue expanding and validating until you are confident the workflow behaves correctly at full scale.

Each round of testing reduces risk. A problem that affects 10 records is far easier to diagnose and reverse than one that has already touched 10,000.

✅

TIP

Keep the workflow in a Disabled state during testing so it does not fire automatically on its schedule. Enable it only once you are fully satisfied with the results at scale.

Confirming the update was successful

Once the workflow has run, you must verify that it completed as intended. A completed run does not automatically mean all records were updated correctly. Here is what to check and where to look.

What to check after running

After a workflow run, check the following:

• Run status on the iWorkflow Dashboard — Look at the vertical bars next to the workflow. Green indicates the run succeeded; red indicates it failed.
• Run log details — Click into the workflow and view the specific run. The log shows each action, whether it succeeded or failed, how many records were processed, and any error messages.
• Record counts — Confirm the number of records processed matches what you expected based on the IQA query used by the iUpdate task.

Where to verify the data

The workflow run log tells you what iDMS did. To confirm the results made it into iMIS correctly, you need to check in iMIS itself:

• Navigate directly to a sample of the affected records in iMIS and confirm the updated fields show the correct values.
• Run the same IQA query that feeds the iUpdate task. If the update worked as expected, the query should return zero records (because all qualifying records were already processed).
• Use a separate IQA query or iMIS report to pull the updated records and spot-check the data.

Understanding "partial" completion

A "partial" result means the workflow run completed but not all records were successfully processed. This can happen when some records encounter errors during the iUpdate action while others succeed.

Common causes of partial results include:

• Individual records that fail validation or have missing required fields.
• Records with data conflicts — for example, a field being updated is locked or has a constraint that prevents the change.
• Timeout or connectivity issues mid-run that interrupt processing before all records are handled.

When you see a partial result, open the run log and look at the action-level details. iDMS typically logs which records failed and why. Use this information to determine the appropriate next step.

When to rerun or manually fix

The right response to a partial or failed run depends on the root cause:

Rerun the workflow if: The failure was caused by a transient issue such as a network interruption, a temporary service outage, or a timeout. If the underlying data and configuration are correct, simply running the workflow again should process the remaining records. iUpdate is generally safe to rerun on records that were already updated — it will only update records that still match the IQA query criteria.

Manually fix and then rerun if: Specific records failed due to data issues — missing fields, format mismatches, or constraint violations. Correct those records in iMIS first, then rerun the workflow or the iUpdate task to pick up the previously failed records.

Do not rerun if: The failure was caused by a configuration error in the workflow or iUpdate task itself (such as an incorrect mapping or wrong field target). Fix the configuration issue first, test with a small dataset, and then re-enable the workflow. Running a misconfigured workflow repeatedly will multiply the problem.