---
title: General features
description: "> Welcome to **Expert Tips**— a growing collection of practical tips and real-world examples to help you get the most out of Extension Kit Core. > > > > This page focuses on the **general features of Extension Kit Core**,…"
url: "https://extensionkit.unitfly.com/documentation/expert-tips-general-features/"
updated: "2026-04-09"
category: Resources / Expert tips
---

# General features

> Welcome to **Expert Tips**— a growing collection of practical tips and real-world examples to help you get the most out of Extension Kit Core.
>
>
>
> This page focuses on the **general features of Extension Kit Core**, found throughout modules.

> To get a new expert tip delivered to your inbox every week, **subscribe to the Tip of the Week newsletter [here](https://pages.unitfly.com/extension-kit-newsletter-subscription).**

---

 Run rules with a Button Click

## Run rules with a Button Click

The **Button Click** trigger in Extension Kit Core lets you execute rules directly from the M-Files UI, without waiting for a workflow or property change. Send documents to ERP, run OCR, ZIP files, and more — exactly when you need it.

The trigger works across all trigger-based modules, as well as modules that normally run automatically, such as Extended Auto Properties.

**Configuration options**

Here’s a closer look at the button action configuration options (Picture 1).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Button-click-1.png)
Picture 1: Button trigger settings

First, you can define **if the rule should apply to**:

- Selected Objects in Current View
- All Objects in Current View
- Objects Set in Rule

Next, choose **where the button appears in the M-Files UI**:

- Three dots menu on the document’s action bar
- Right-click menu on a document (or an empty space in a view)

Then, use the **Button label** field to set custom text displayed on the button.

To guide users, configure messages that appear during execution:

- **Confirmation message** – displayed in a pop-up before running the rule (Picture 2)

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Button-click-2.png)
Picture 2: Confirmation message example.

- **Success message** – displayed when the rule executes successfully (Picture 3)

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Button-click-3.png)
Picture 3: Success message example.

- **Error message** – displayed if the rule fails.

Finally, use **Order** to define where the rule appears in the dropdown list.

**Example**

Let’s say you have a rule that applies encryption to selected documents with a button click (Picture 4).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Button-click-4.png)
Picture 4: Rule configuration example.

In M-Files, open the three dots menu of the document and select the rule (Picture 5). The document is encrypted instantly (Picture 6).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Button-click-5.png)
Picture 5: Select the rule in the three dots menu.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Button-click-6.png)
Picture 6: The rule is executed, and the document is encrypted.

---

 Syncing related properties between object types

## Syncing related properties between object types

In this week's tip, we're tackling a common scenario - asked recently in our community - where related properties need to

**The Challenge**

You have an **Employee** object type with a multi-select property called **Customers**, containing a list of customers. Meanwhile, your **Customer** object type has a single-select property **Employee**, indicating the assigned employee. Since each customer can have only one project leader, but an employee can manage multiple customers, you want changes made in one object type to be automatically reflected in the other.

**The Solution**

Here’s how to set up synchronization using an orchestrated rule that automatically updates properties between two object types:

1. **Create an Orchestrated Rule** within Property Operations where **Customer** is the trigger source.
2. **Rule 1:** Search for **Employee** using an indirect reference and remove *self (%.%)*.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/sync-image-1.png)

3. **Rule 2:** Directly search for the same **Employee** and append self (%.%).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/sync-image-2.png)

This setup ensures that whenever a customer is added or removed from an employee, the changes are automatically reflected in both the **Employee** and **Customer** object types.

**Important:** Make the **Customers** property on the Employee object **Read-Only** to ensure that the Customer object remains your single source of truth.

By automating the synchronization of these properties, you’ll save time, reduce errors, and keep your data consistent across your organization.

---

 Using regular expressions in Extension Kit Core

## Using regular expressions in Extension Kit Core

Regular expressions (regex) are a powerful way to extract, transform, or validate text — and you can use them in multiple modules in Extension Kit Core to automate and streamline your M-Files processes. In this week’s tip, we’ll show you:

- Examples of what you can do with regex in Extension Kit
- Where regex is supported in Extension Kit
- A practical use case with the Property Operations module
- Best practices for writing and testing regex patterns

**Using regex in Extension Kit**

With the regex operator, you can manipulate, validate, and extract data across multiple modules in Extension Kit. Regex can be used to split or format property values, create validation rules that ensure specific conditions are met, and extract values based on defined patterns — enabling dynamic property calculations from text input. It also helps identify files that belong to the same object during imports, improving data organization and accuracy. In more complex workflows, regex can play a key role in orchestrating data flows and calculations, supporting automation, and maintaining data integrity throughout your M-Files configuration.

Regex is currently supported in the following modules:

- Orchestrator
- Property Operations
- Email Notifications
- Extended Auto Properties
- Auto Numbering Properties
- Object Operations
- Validation
- SQL Integration
- HTTP Integration
- Excel Reader
- Word Reader
- Versioning
- Reporting
- Data Transfer

**Example: Extracting a country code from a phone number**

On a **Customer** object, we have a property storing phone numbers in this format:

`+385 91 123 4567`

When the object changes, we want to extract just the **country code** (e.g., `+385`) and store it in a separate property on the source object. To capture the **+ and 1–3 digits** at the beginning of the string followed by a space, we’ll use this regex pattern:

```
^\+?\d{1,4}
```

Here’s how to configure this rule in Property Operations (Picture 1):

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/regex1.png)
Picture 1: Rule configuration for using regex to extract a country code from a phone number.

**The result**

When a phone number is entered, the rule extracts the country code and saves it to the target property (Picture 2).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Regex2-1024x611.png)
Picture 2: The country code is extracted from the phone number and saved as a separate property on the source object.

**Best practices when using Regex**

- Use a dedicated site to build, test, and debug your regex patterns. For example, we like to use [regex101.com](https://regex101.com/), as it highlights matches and shows capturing groups - which is both useful when setting up Extension Kit rules.
- Start small and test your patterns on real data before deploying.
- Document your regex patterns in the rule descriptions for clarity.

Regex can help you clean and structure data automatically, adding flexibility and precision to your M-Files configuration.

---

 Make rule testing easier with Run Once

## Make rule testing easier with Run Once

When testing Extension Kit Core rules, it’s common to rely on changing object states, adding comments, or creating objects to trigger rule execution. But doing those steps repeatedly just to check if your rule works can be time-consuming, not to mention a bit frustrating.

That’s where the **Run Once** feature on the Dashboard comes in.

**What is Run Once and how it works**

**Run Once lets you manually trigger a rule once**, executing it on all matching objects in the vault. It’s especially useful during testing and configuration.

Here’s how to use it:

1. Set up your rule as usual.
2. Set the trigger to **Run Once.**
3. Go to the **Dashboard** tab.
4. Click the **Execute RunOnce rules** button within the desired module.

All rules with the **Run Once** trigger in that module will run immediately, without the need to simulate a workflow or perform repetitive actions.

**Example use case**

Let’s say you’re configuring an email notification and want to make sure everything looks right — clean formatting, no typos, and all the details in place. Instead of repeatedly adding comments or changing states on the same object, you can configure a rule like this (see Picture 1):

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Run-once-1.png)
Picture 1: Example rule configuration in the E-mail Notifications module.

To test the rule, go to the **Dashboard** tab and click **Execute RunOnce rules** under the E-mail Notifications module (Picture 2). It’s a faster and cleaner way to test your configuration, without cluttering the vault or wasting time.

And if the rule takes a while to execute? You can stop it directly from the same screen using the **Stop RunOnce rules** button.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Run-once-2.png)
Picture 2: Test the rule with the **Execute RunOnce rules** functionality.

Run Once can be a great time-saver when you're fine-tuning a rule and want to test the output multiple times. Next time you're testing, use Run Once— it’s a simple feature that can make a big difference.

---

 Advanced use of Vault Search

## Advanced use of Vault Search

In the Property Operations module, the **Vault Search** feature is typically used to find an object whose property value should be set based on a value from the Trigger Source, or vice versa — to retrieve metadata from a related object and apply it to the Trigger Source.

This tip starts with a quick introduction to Vault Search, then dives into advanced use cases showing how to use Vault Search to **filter the Trigger Source based on data from multiple related objects in the vault.**

**Basic Vault Search functionality**

Here’s a classic use case to illustrate how Vault Search works.

A rule in the Property Operations module (Picture 1) uses Vault Search to set the **Invoice Owner** property based on the **Created by** property of the **Invoice** object. Since Created by stores the **Login Account** of the user who created the object, and Invoice Owner expects an **OT** **Employee**, we can’t directly copy the value.

Instead, Vault Search helps by locating the Employee whose Login Account matches the Created by value. That Employee is then assigned to the Invoice Owner property.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Vault-search-0.png)
Picture 1: Example rule configuration for Vault Search in the Property Operations module.

**Advanced filtering options**

In addition to this intuitive usage, Vault Search can also serve as an **advanced filtering step** that extends your ability to filter objects across the vault. While Trigger Source filtering only allows filtering its own properties, **Vault Search lets you define conditions the Trigger Source must satisfy based on information from other related objects in the vault.**

In an **invoice processing** scenario with **Vendor** and **Invoice** objects, you might want to evaluate a *Vendor* based on data from its related *Invoices*, such as:

- Have they issued an unusually high-value invoice?
- Do they have any unpaid invoices?
- How long has it been since their last invoice?

Vault Search checks related *Invoices* and determines whether the *Vendor* meets the specified criteria, executing the rule **only when those conditions are met**. You can configure it to:

- Execute the rule if **at least one related object** matches the criteria (**Search Result Type = Any**), or
- Execute the rule **only if no related objects** match the criteria (**Search Result Type = None**).

Important: If the rule is orchestrated, make sure to set the **Use vault search** option to **Yes** to retain this behavior.

**Example 1: No invoices in the last year (Search Result Type = None)**

This rule sets the **Activity Status** of any Vendor to **Inactive** if they haven’t had any invoices in the past 12 months. If Vault Search returns no results, the condition is met, and the Activity Status property is updated (Pictures 2 and 3).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Vault-search-1.png)
Picture 2: Vendor’s Activity Status will be set to **Inactive** if they haven’t had any invoices in the last year.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Vault-search-2-2.png)
Picture 3: Vendor’s Activity Status will be set to Inactive if they haven’t had any invoices in the last year.

**Example 2: Vendor has unsettled invoices (Search Result Type = Any)**

In this case, the rule identifies each Vendor, finds all related Invoices using Vault Search, and checks if any invoice has the property **Settled** set to **No**. If even one such invoice exists, Vault Search returns a result, and the **Unsettled Invoices** property on the OT Vendor is set to **Yes** (Pictures 4 and 5).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Vault-search-3.png)
Picture 4: Vault Search identifies invoices where Settled = No and updates the Vendor’s Unsettled Invoices property to Yes.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Vault-search-4-1.png)
Picture 5: Vault Search identifies invoices where Settled = No and updates the Vendor’s Unsettled Invoices property to Yes.

Vault Search provides a powerful, flexible way to **filter objects based on data spread across multiple objects in the vault.** Along with the Orchestrator and Validation modules, Search filters, and Dynamic search conditions, Vault Search expands your ability to validate and automate processes on objects across the vault, increasing speed and efficiency in the configuration process.

---

 Advanced scheduling with cron expressions

## Advanced scheduling with cron expressions

Need to run a rule every workday at a specific time, or just on the second Friday of each month?

The **Scheduled** trigger type in Extension Kit Core lets you define when rules should run. You can set basic frequencies like once, hourly, daily, etc. — but if you need more precision, you can create custom schedules using **cron expressions.**

**What is a cron expression?**

A cron expression is a five-part string that represents a schedule for executing tasks at specific times or intervals. Each part represents a unit of time:

- **Minute** (0-59)
- **Hour** (0-23)
- **Day of Month** (1-31)
- **Month** (1-12)
- **Day of Week** (0-6, where 0 = Sunday)

For example, a cron expression like **`0 12 * * 1`** would schedule a task to run at 12:00 PM every Monday.

**Using cron in Extension Kit Core**

When scheduling with cron, Extension Kit uses this expression as a default value: **`*/5 9-17 * * *`**

Which means: **Every 5 minutes, from 9 AM to 5 PM, Monday through Friday** (Picture 1).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Cron.png)
Picture 1: The default cron expression in EK Core.

**Example use cases**

Here are a couple of practical cron expression examples:

- **Automated invoice syncing:** Using the HTTP Integration module, fetch invoices from a service every 20 minutes during working hours: **`*/20 9-17 * * *`**
- **Biweekly contract archiving:** Using the Archiving module, archive contracts every second Friday at 5 PM: **`0 17 */14 * 5`**

**Not sure if your expression is correct?** Use the [**cron helper**](https://cron.help/) to explore and test cron expressions easily.

If your process needs precise timing, cron expressions give you the flexibility to match your rules to real-world business schedules — down to the minute.

---

 Use filename wildcards to target specific files

## Use filename wildcards to target specific files

When working with **multi-file documents** in M-Files, you often need to fetch or process only **specific files** within a multi-file document. That’s where **filename wildcards** in Extension Kit Core come in handy. They allow you to specify which documents to include or exclude.

**What is a filename wildcard?**

A filename wildcard is a special character (or set of characters) used to match filenames or patterns in file systems. It helps you filter and select the right document(s) when an object includes multiple files.

**Example: Filtering specific files in a multi-file document**

For example, let’s say you have a multi-file Contract document with the following files:

- `Annex_A.pdf`
- `Annex_B.pdf`
- `Contract.docx`
- `NDA.docx`

You want to archive **only the NDA documents** for all employees using the Archive module. In this case, you would use the filename wildcard *NDA*, which will pick up all files containing "NDA" in their name, while ignoring Annex and Contract files (Picture 1).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Filename-wildcards-0.png)
Picture 1: Example of a multi-file object.

**Filename wildcards in EK Core**

In Extension Kit Core, you mainly use two wildcard patterns:

- * that matches any number of characters Example: `file*` matches `file`, `file1`, `file_test.txt`, etc.
- File-type specific wildcards, like `*.pdf`, `*.docx`, `*.jpg`

**Example use case: Cleaning up multi-file email documents**

Imagine your company receives invoices via email attachments in common formats like PDF, XLS, and DOC. In M-Files, you've configured the **Connections to External Sources** to import these emails with attachments into M-Files.

The resulting M-Files object is a multi-file document that may include:

- An image from the email signature (`.jpg`)
- The email body (`.html`)
- The actual invoice attachment in its original format

Since you only need the invoice, you can use the **Document Processing** module to create a rule that keeps only files matching `*.pdf`, `*.xls`, `*.doc,` and deletes the rest (like `.html` and `.jpg`) (Picture 2).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/07/Filename-wildcards.png)
Picture 2: Configuration example of specifying documents using filename wildcards.

Using filename wildcards helps you easily target exactly the files you need from multi-file objects, keeping your objects clean and focused on the documents that matter.

---

 Instantly update metadata within documents

## Instantly update metadata within documents

Keeping data in sync is even easier with Extension Kit Core. Did you know you can **automatically update values within documents** whenever metadata changes in M-Files, **without the need for check-out?**

**Updating metadata in documents**

When mapped properties are used in a document, they need to be updated each time a corresponding M-Files property changes. Typically, this would require checking out and checking in the document for the mapped properties to be updated.

However, with the **Update metadata in file** setting, all changes are **immediately visible in the preview section, even without checking out the document**. This feature, available in advanced configuration mode, enables **instant updates to any mapped properties** whenever a corresponding M-Files property is modified by a rule in which this option is enabled.

**Example**

A **Contact Document** object has a **Document Title** property calculated via an Extension Kit rule (Picture 1). Every time the **Customer** changes in M-Files, all properties should be updated instantly within the associated document.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Update-metadata-in-file-1-Edited.png)
Picture 1: Whenever the Customer changes, all properties need to be updated within the document.

**How it works**

Instead of updating the value manually via document check-out and check-in, all you need to do is **enable the** **Update metadata in file** setting in the rule configuration of Extension Kit Core (Picture 2):

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Update-metadata-in-file-2a.png)
Picture 2: Enable **Update metadata in file** to update values instantly, without check-out.

As a result, with any change of the property calculated by this rule, all mapped values within your document will update automatically. These modifications are instantly reflected in the preview card without the need for check-out (Pictures 3 and 4).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Update-metadata-in-file-3-Edited.png)
Picture 3: Mapped values within documents are automatically updated whenever the rule is executed.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Update-metadata-in-file-4-Edited.png)
Picture 4: Once the metadata changes, updated values are visible in the preview card without requiring check-out.

This feature ensures that your documents always reflect the latest metadata, reducing manual updates, unnecessary check-outs, and potential errors.

---

 Optimizing rule execution with Monitored properties

## Optimizing rule execution with Monitored properties

When configuring rules in Extension Kit, it’s important to control how often they execute. By default, a rule is triggered by **any change** to the source object. However, not every change is relevant, and unnecessary executions can impact system performance.

To improve performance, use **Monitored properties** to specify which property changes should trigger the rule. This ensures that rules run only when needed, bringing several benefits:

- **Reducing unnecessary executions:** If no monitored properties are set, the rule runs on *every* object change, even when the modification is irrelevant. This can lead to excessive rule executions, consuming system resources unnecessarily.
- **Optimizing system performance:** Rules execute only when specified properties change, reducing the processing load on M-Files and Extension Kit, and improving overall system efficiency.
- **Preventing workflow bottlenecks:** Avoiding slowdowns caused by excessive rule executions.
- **Enhancing precision and control:** Ensuring rules respond only to meaningful metadata updates.

There is also a possibility of **setting a condition under which a property would be monitored.** If multiple **Monitored property conditions** are set, they are combined using the **OR** operator, meaning a change to any of them will trigger the rule.

**Best practice:** Always define Monitored properties when your rule only depends on specific metadata changes. This keeps your system efficient and responsive!

---

 Keep your configuration safe with backups

## Keep your configuration safe with backups

Did you know you can **backup configurations in Extension Kit Core**?

When multiple people work on the same vault — adding rules or editing settings — unexpected errors can happen. In those moments, having access to an older configuration can save hours of troubleshooting.

**Configuration backup settings**

Under **Advanced settings,** the **Configuration backup settings** (Picture 1) let you **automatically back up the configuration** every time it’s updated.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Configuration-backup.png)

You can **store backup** to:

- **Disk** – specify a folder path.
- **Vault** – specify the object, class, and M-Files user.
- **NVS** – save directly to Named Value Storage.

For each destination, you can also set **Backup files retention** to determine how long to keep the backup files. If you set the value to 0, backups are never deleted based on age.

**When to use backups**

In **test environments**, frequent changes can generate many backup files, so you may want to disable Configuration backup there.

But in **production**, backups are a lifesaver. If an error appears, you can easily check whether a rule was added, something was deleted, or another change was made that could have caused the issue.

---

 Choosing the right trigger: *Object entered state* vs *Object left state*

## Choosing the right trigger: *Object entered state* vs *Object left state*

Ever wondered whether to use *Object entered state* or *Object left state* in your rule? The difference may seem small, but choosing the right trigger is key to getting your workflow logic right.

In this tip, we’ll explore the same use case using both options to show how each one behaves.

***Object entered state* vs *Object left state***

- **Object entered state:** Executes the rule when the source object enters a specific workflow state.
- **Object left state:** Executes the rule when the source object leaves a specific workflow state.

**Use case**

Let’s say an office manager receives invoices in the state *Invoice Received*. They can either **approve** or **reject** an invoice, but in some cases, the invoice must be reviewed by the Department Manager or the Finance team, who will then decide whether to approve or reject it (see the workflow in Picture 1).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Triggers-1-1024x718.png)
Picture 1

When an invoice is **rejected**, you want to **send an email notification** to the person listed in the **Responsible Person** property.

However, the right trigger depends on **how detailed** you want the information to be.

**Example #1: When you only need to know that the invoice was rejected**

If you simply want the Responsible Person to receive a notification that the invoice has been rejected, regardless of who rejected it, use the **Object entered state = Rejected** trigger (Picture 2).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Triggers2.png)
Picture 2

This way, whenever the invoice enters the *Rejected* state, the rule executes and sends the email (Picture 3).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Triggers-3-Edited-1024x856.png)
Picture 3

**Example #2: When you need to know who rejected the invoice**

If you want to notify the Responsible Person **who rejected** the invoice, you can use the **Object left state** trigger. Each state (*Invoice Received*, *Department Manager Review*, *Finance Review)* will have its own rule that sends an email upon leaving that state.

However, since an invoice also leaves a state when it’s approved, you need to ensure emails are sent **only for rejections.** To do this, add a condition:

- In the *Rejected* state, the **Rejection Reason** **property must not be empty**.
- In the *Approved* state, the **Rejection Reason** **property must be empty**.

Then, in your **Object left state** rule, add the condition *Rejection Reason is not empty* (Picture 4).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Triggers-4.png)
Picture 4

This ensures the email is sent **only when the invoice moves to *Rejected***, and you can include in the message **who rejected it** (Picture 5).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Triggers-5-Edited-1024x880.png)
Picture 5

**Conclusion**

When the previous state contains information essential for the next steps in the process, the rule should be triggered **when the object leaves that state**. If all the necessary information is available in the state the object is entering, then trigger the rule **when the object enters the state.**

---

 Managing Extension Kit Core versions

## Managing Extension Kit Core versions

Upgrading or downgrading your Extension Kit Core version is simple, but here are some important steps and tips to keep in mind:

1. **Upgrading Extension Kit Core**

If you want to upgrade, select Extension Kit in your Applications, click **Install**, and the new version will be applied (Picture 1).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Managing-EK-versions-1-1024x636.png)
Picture 1

2. **Downgrading Extension Kit Core**

If you need to downgrade for any reason, you must **Uninstall** Extension Kit first, then **Install** the desired version (Picture 2). Before downgrading, note that it’s useful to **export your entire configuration.** This allows you to restore it easily if you later return to a higher version.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Managing-EK-versions-2-1024x636.png)
Picture 2

3. **License installation**

Whenever you change the Extension Kit Core version, always **Install License** again (Picture 3).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Managing-EK-versions-3-1024x779.png)
Picture 3

4. **Refresh configuration**

After changing versions, make sure to **Refresh** Configurations so that all changes are synced correctly (Picture 4).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Managing-EK-versions-4.png)
Picture 4

---

 Ways to create objects in Extension Kit Core

## Ways to create objects in Extension Kit Core

Extension Kit Core makes creating objects in M-Files **convenient and efficient**, no matter where your data comes from. Covering a wide range of business use cases, it gives you incredible **flexibility to automate and streamline object creation.**

Here are the eleven modules where objects can be created:

- **Object Operations** – Create objects based on a trigger. For example, when an **Employee** object moves to the **Active** state, an NDA can be created automatically.
- **HTTP Integration** – Create objects directly from an HTTP response.
- **SQL Integration** - Create objects from an SQL query response.
- **Excel Reader** – Create objects from data stored in Excel sheets.
- **Word Reader** – Create objects using data extracted from Word documents.
- **Document Processing** – Create new objects when splitting or merging documents.
- **Data Transfer** – Create objects when importing documents from SFTP or file shares.
- **Vault to Vault** – Create objects in the current vault or in another vault.
- **Reporting** – Generate a report as a new object.
- **Archiving** – Save compressed or decompressed files as new objects.
- **Extension Methods** – Create new objects via custom extension methods.

Whether you’re working with imported files, documents, APIs, or metadata, Extension Kit Core lets you automate object creation in the way that best fits your process.

---

 Relationship between Execution Mode and Copy Mode

## Relationship between Execution Mode and Copy Mode

As part of Extension Kit's advanced configuration, the **Execution mode** feature allows you to define when a rule is executed.

**Understanding Execution Mode options**

The key difference between the execution mode options lies in when the changes are applied:

- **EventHandler**: Executes changes during the object check-in process.
- **Background** and **BackgroundTransaction**: Executes changes after the object has been checked in.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/execution-mode-tip-1.png)

**How Execution Mode relates to Copy Mode settings**

The **Copy mode** settings within the Property Operations module directly influence the default **Execution mode**:

- When **Copy mode** is set to **FromSourceToTarget**, the default Execution mode will be **BackgroundTransaction**.
- When **Copy mode** is set to **OnSourceObject**, the default Execution mode will be **EventHandler**.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/execution-mode-tip-2-1024x194.png)

While you can customize these settings to suit your specific use case, it's important to understand the relationship between these two functionalities to ensure optimal configuration. For a more detailed explanation of Execution mode, please refer to the documentation [here](https://toolkitformfiles.unitfly.com/documentation/rule-execution/#execution-mode).

---

 Understanding Direct vs. Indirect Reference Direction

## Understanding Direct vs. Indirect Reference Direction

In Extension Kit, some modules allow you to search and find target objects via a specific property. When doing so, you have the option to specify the reference direction.

Let's dive into what this feature means and how to distinguish between direct and indirect reference directions.

**Direct vs. Indirect Reference**

When establishing a relationship between a source object and a target object, the connection can be either direct or indirect:

- **Direct Reference (Default):** Use this option when the source object directly references the target object through a specific property. This means the source has a direct link to the target, which can be used to identify and manipulate the target.
- **Indirect Reference:** Select this option when the target object references the source object. In this scenario, the relationship is reversed—the target knows about the source, not the other way around.

**Example**

Consider a scenario where you want to automatically change the workflow state of an Opportunity to "Won" whenever an Offer reaches the "Accepted" state. This is achievable with the Property Operations module.

- **Trigger Source:** Offer
- **Target:** Opportunity

Here's how the reference directions work in this example:

- **Direct Reference direction:** If the Offer object has a property named Opportunity, which is a lookup to Opportunity objects, this is a direct reference. When the Offer’s state changes to "Accepted", the system will find the associated Opportunity using the direct reference and set its workflow state to "Won".

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/direct-relationship.png)

- **Indirect Reference direction:** Suppose the Offer does not have a direct reference to the Opportunity. Instead, the Opportunity has a reference to the Offer. In this case, you would set the reference direction to indirect. By specifying that the reference property is the Offer, the system will locate the Opportunity that references the Offer and update its state to "Won" accordingly.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/indirect-relationship.png)

Understanding whether to use a direct or indirect reference is key to ensuring that your automation workflows behave as expected.

---

 Take full advantage of the Dashboard

## Take full advantage of the Dashboard

Whether you're testing rules, tracking background tasks, or just checking your license status, the **Dashboard**in **Extension Kit Core** is your go-to place for everything happening behind the scenes.

Let’s break it down.

**Key application info**

The top section of the Dashboard (Picture 1) gives you essential details:

- **Extension Kit Core version**
- **License status** (valid or expired)
- **List of licensed modules**
- **Service data** such as serial number, license expiry date, and SEQ API key (for log tracking in SEQ)

You’ll also find two useful buttons:

- **Refresh Dashboard**: Updates rule execution and scheduling status. Especially useful during testing (e.g., Run Once/Scheduled rules) or when monitoring long-running rules.
- **Destroy Task Queues**: Emergency only! Clears all queued rules. This is helpful during testing if a rule locks the vault, but avoid using it in production, as it may disrupt valid rule execution.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Dashboard-1-1024x544.png)
Picture 1: Key application info in the Dashboard.

**Modules overview**

The module table (Picture 2) displays:

- Module’s status (enabled/disabled)
- A short description of each module

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Dashboard-2-1024x506.png)
Picture 2: The modules overview in the Dashboard.

If a module supports **Run Once** execution, you’ll see dedicated buttons to:

- **Execute RunOnce Rules**
- **Stop RunOnce Rules**

Once configured, any active RunOnce rules are listed right below the module description for easy tracking. After execution, completed rules are moved to the **RunOnce rules** table in the Dashboard.

**Monitor background tasks**

If a rule is configured with **Execution Mode: Background**, a dedicated **Background Tasks** table appears in the Dashboard. This helps you track the execution status and catch issues as they happen. Below is an example of a RunOnce rule in the Reporting module with the background tasks listed (Picture 3).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Dashboard-3.png)
Picture 3: Background tasks

**Recalculate properties with one click**

For the **Extended Auto Properties**, **Auto Numbering**, and **Property Builder** modules, the Dashboard gives you control over property recalculation:

- **Recalculate Properties**: Triggers recalculation on all relevant objects.
- **Stop Recalculation**: Halts the process if needed (Picture 4).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Dashboard-4.png)
Picture 4: Recalculate properties

**View & download logs**

If **Logging** is enabled and a **Default target** is set, users can:

- **View the latest logs**
- **Download logs directly** from the Dashboard

You’ll also see a list of all configured log targets (e.g., File, SEQ) along with their corresponding log levels. (Picture 5)

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Dashboard-5.png)
Picture 5: Logging

**Track asynchronous rule execution in real time**

The **Asynchronous Operations** section (Picture 6) shows the status of rules that aren’t triggered by event handlers. You can monitor:

- Execution status (Completed/Failed)
- Scheduling status
- Errors or misconfigurations

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Dashboard-6.png)
Picture 6: Asynchronous operations

Tip: Use the **Refresh Dashboard** button to update the table and check current statuses. For example, if you run a rule using the Execute Run Once rules button, it will appear in the table immediately (Picture 7), but it won’t show as Completed or Failed until you refresh.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Dashboard-7.png)
Picture 7: RunOnce rules

The Dashboard is packed with insights that help you **troubleshoot faster, manage smarter, and test safer**.

---

 Keep your Extension Kit configuration organized

## Keep your Extension Kit configuration organized

As your Extension Kit Core configuration grows, keeping it organized becomes key. To help you **maintain an orderly configuration**, here are some best practices for managing **Rule groups, Rules, Descriptions, and Aliases**.

**Rule groups and rule names**

- As each module is designed to have **rule groups** that can contain one or more rules, a good starting point is to structure rule groups based on **M-Files Object Types**, and then organize rules within the groups based on actions performed on the objects (Picture 1). To name rules, use descriptive titles that clearly explain what the rule does and which classes it affects.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Organizing-1.png)
Picture 1: Organizing rule groups based on M-Files Object Types.

- For Object Types with many classes, like OT Document, it makes sense to organize and name rule groups by **Object Type and Class**, and rules by **specific actions (Picture 2)**:

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Organizing-2.png)
Picture 2: Organizing rule groups based on Object Type and Class.

- Sometimes it’s best to **create rule groups for a specific action**, so changes can be made without searching through the entire module. For example, if mSign performs actions on both OT Document and OT mSign Signature objects, place them in the same rule group rather than splitting them by object type (Picture 3):

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Organizing-3.png)
Picture 3: Organizing rule groups based on a specific action.

-

**Rule descriptions**

The **Description** field is crucial for future edits or when handing over your configuration to someone else (Picture 4).

Think of descriptions like comments in coding - they make navigating and maintaining your configuration much easier, even if they feel like extra work at first.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Organizing-4.png)
Picture 4

**Aliases**

Aliases are essential for making rules accessible across modules:

- Without an alias, configurations set in the **Environments** module cannot be used in other modules (Picture 5).
- In the **Orchestrator** module, only rules with aliases are visible in the configuration.

**Tip:** After adding an alias, refresh your configuration and/or restart the vault to ensure it’s visible in other modules.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Organizing-5-1024x728.png)
Picture 5

A well-organized configuration makes your Extension Kit Core setup easier to maintain, reduces errors, and saves time in the long run.

---

 Multi-level references

## Multi-level references

Reaching referenced objects in M-Files got easier and faster. Beyond single-level references, you can now find targets using **multi-level references** in Extension Kit Core.

Let’s break down the difference between these levels and see how you can use them.

**Single-level reference**

If you want to reach an object that is **directly or indirectly referenced** on the trigger object, you can use a **single-level reference**.

**Example:**

Suppose a **Project** is your trigger object. You want to find all **Tasks** related to that Project. A single-level reference works if:

- The **Project** object contains a direct reference to its **Tasks**, or
- The **Task** object contains a reference back to its **Project** (indirect reference). (Picture 1)

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/multi-level-reference-1.png)
*Picture 1: The **Task** object contains a reference to its **Project.***

But what if the trigger and target objects aren’t **directly** connected by references?

**Multi-level reference**

A multi-level reference is a chain of connected objects that helps you **reach target objects through multiple reference levels.** Each level can be filtered, and connections can be direct or indirect.

This allows Extension Kit to follow relationships that aren’t immediately visible on the trigger object, **without performing additional vault searches.**

**Example:**

You want to find all **Hour Logging Events (HLEs)** related to the Project’s Tasks. HLEs aren’t referencing the **Project**, but only the Task (Picture 2), so reaching these HLEs isn’t possible using **single-level** references alone.

Before multi-level references, you had to search all HLEs in the vault and then filter those whose Task belongs to that Project.

Now, with **multi-level references**, you can follow the chain *Project → Task → HLE* and reach those HLEs even though they aren’t directly connected to the Project.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/multi-level-reference-2.png)
*Picture 2: HLEs are referencing a Task.*

**Configuration example**

A rule triggers on the **Project** and is designed to **send a report of all related HLEs to the Project Manager.** Using multi-level references, the rule automatically:

1. Finds all Tasks where `PD.Project` references the Project.
2. Finds all HLEs where `PD.Task` references any of those Tasks. (Picture 3)

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/multi-level-reference-3.png)
*Picture 3*

**Result**: A simpler configuration, no vault search needed, and much faster rule execution.

---

 Customizing Logging in Extension Kit Core

## Customizing Logging in Extension Kit Core

In addition to developing new features, our team continuously works on improving logging — tracking all tasks executed within Extension Kit Core. Clear and consistent log messages make it much easier to develop, test, and automate any process.

**Logging in Extension Kit Core**

Logging can be fully customized to fit your needs, with all details defined directly in the configuration:

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Logging-1.png)

Within the configuration, you can define one or more **targets** (locations where logs will be exported). The **Default File Target** refers to logs that can be downloaded directly from the Dashboard:

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Logging-2.png)

**Example**

Let’s look at setting up a **File target**.

- The **Default Log Level** can be adjusted based on your needs and can be set to **Trace, Debug, Info, Warning, Error,** or **Fatal**. A recommended best practice is:
  - For a detailed overview when troubleshooting issues, use **Debug** level (note that **Trace** is extremely detailed)
  - For general operation, especially in production environments, use **Info** level

For example, once your production setup is stable and error-free, you can keep the log level at Info. If an issue occurs, temporarily switch to Debug or Trace to investigate, and then revert to Info once the issue is resolved.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Logging-3.png)

- After selecting the log level, define the **Folder Path** where the logs will be exported.
- Under **Advanced settings**, you can also specify the **Log Message Format**. The recommended log message format is:

`${longdate} [${level:uppercase=true:padding=3}]${logger} [Task:${mdlc:TaskID}] [${mdlc:ModuleName}]${mdlc:Vault}${mdc:Rules}${message}${onexception:${newline}${exception:format=ToString:innerformat=ToString:separator=\\r\\n}}`

For additional guidance, [explore more tips for efficient Logging in Extension Kit Core](https://extensionkit.unitfly.com/documentation/expert-tips-other-modules/#best-practices-for-efficient-logging-in-extension-kit-core).

Although logs may initially seem complex and difficult to follow, with a bit of practice, they become an extremely valuable source of information and a powerful tool for testing and troubleshooting potential configuration issues.

---

 Assign the actual user as the last modifier

## Assign the actual user as the last modifier

Have you ever noticed that when a rule updates a document automatically, the **Last modified** field shows **M-Files Server** instead of the actual user?

For example:

- A user moves a document to the next workflow state → **the user is shown as the modifier**
- A background rule then updates a property or creates a new version → **M-Files Server becomes the last modified user**

This way it can be confusing for end users to determine who last changed a document.

That’s where the **Act as User** functionality comes in.

**What is Act as User?**

The **Act as User** option, available in modules such as **Property Operations**, **Document Processing**, **SQL Integration**, and **HTTP Integration,** controls which user is shown as **Last modified** after the rule is executed.

It allows you to attribute changes to the real user who initiated the action, rather than to M-Files Server. The options are:

- **None:** M-Files Server is shown as the last modifier.
- **LastModified:** The last user who modified this object before the rule was executed (it can also be M-Files Server).
- **LastActualUserModified:** The last real user account that made changes to this object.

**Example: Workflow-triggered PDF conversion**

Let’s look at a simple example.

A document moves through a workflow. When it enters the **Convert to PDF** state, an Extension Kit Core rule converts the document to PDF. See the configuration below (Picture 1).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Act-as-user-1.png)
Picture 1

The document was created by the user **Unitfly Demo**. This same user then moved the document into the **Convert to PDF** state. Since the workflow transition was performed manually, the **Last modified** property correctly shows **Unitfly Demo** at this stage (Picture 2).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Act-as-user-2.png)
Picture 2

This workflow transition then automatically triggers the PDF conversion, and the displayed last modifier depends on the **Act as User** setup.

**Without Act as User**

If **Act as User** is not configured, **Last modified** shows **M-Files Server** as the last modifier, because the PDF conversion is executed by Extension Kit Core (Picture 3).

While the version history shows that the Unitfly Demo user initiated the action, end users typically rely on the metadata card rather than the version history. As a result, they expect the **Last modified** value to reflect the person who last worked on the document.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Act-as-user-3-690x1024.png)
Picture 3

**With Act as User enabled**

When **Act as User** is configured, Extension Kit assigns the **Last modified** value to the user who moved the document into the triggering state (Picture 4).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Act-as-user-4.png)
Picture 4

After the rule is executed, the metadata card looks like this (Picture 5). **Last modified** no longer shows **M-Files Server**, but the actual user who triggered the workflow action.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/Act-as-user-5-816x1024.png)

---

 New triggers for file manipulation detection

## New triggers for file manipulation detection

Sometimes it’s important to distinguish between **metadata changes** and **changes made to the document file itself**.

For example, rules in Extension Kit Core could previously be triggered by events such as:

- **any change to the object**, including both file and metadata (Object changed)
- **changes to metadata only**, without reacting to modifications of the file (Object metadata changed)

With [v26.2.0](https://extensionkit.unitfly.com/documentation/release-notes/#2620), we’ve introduced additional options that **trigger rules specifically to file-level changes**.

**New triggers: File changed, File added, File removed**

New triggers are now available across **file-based and trigger-based modules**, allowing rules to react specifically to file manipulation (Picture 1):

- **File added** – triggers when a new file is added to the object (particularly useful for multi-file documents)
- **File removed** – triggers when a file is removed (also particularly useful for multi-file documents)
- **File changed** – triggers when any change is made to the file, for example: editing a Word document, converting a file to PDF, or adding/removing files

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/File-triggers-1.png)
Picture 1

**Use case & configuration example**

Suppose you have a class called **Technical Documentation**. Users can create documentation directly in M-Files, but they can also drag and drop files into the object (Picture 2).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/File-triggers-2.png)
Picture 2

When a **new file is added to a multi-file Technical Documentation object**, you want the Project Manager to receive **an email notification.**

This can be configured using the **File added** trigger (Picture 3).

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/File-triggers-3.png)
Picture 3

**Result**

With this configuration, the **Project Manager receives an email only when a new file is added** to the multi-file document (Picture 4).

The rule will **not trigger** if object metadata changes, if the object moves to another workflow state, or if other non-file-related updates occur.

![](https://extensionkit.unitfly.com/wp-content/uploads/2025/10/File-triggers-4-1024x438.png)
Picture 4

---

 Choosing the right Execution mode

## Choosing the right Execution mode

Extension Kit Core rules can run in three execution modes:

- **EventHandler**
- **BackgroundTransaction**
- **Background**

The execution mode determines **when the rule runs, how users experience the execution, and how errors are handled**.

You can find [a detailed technical description of each mode](https://extensionkit.unitfly.com/documentation/rule-execution/) in the **Extension Kit Core documentation**.

In this tip, we’ll look at the differences **from the user’s perspective** using a practical example.

**Use case example**

Consider the following scenario:

- A **Project** object contains a **Project Manager** property.
- All documents related to that project have a **Document Owner** property, where the **Project Manager** is assigned.

When the Project Manager changes, a **Property Operations rule updates the Document Owner** property on every related document.

The execution mode determines how this update happens and how the user experiences it.

**EventHandler behavior**

When the user changes the **Project Manager** and clicks **Save**:

- The Project **will not be saved** until the rule finishes updating all related documents.
- During execution, the **user interface remains locked**, and the user **cannot continue working in M-Files.**

If the rule does not complete within the default **90-second scripting timeout**, execution stops and a validation error is returned.

**BackgroundTransaction behavior**

When the user changes the **Project Manager** and clicks **Save**:

- The Project **saves immediately**.
- The rule then runs **in the background** and updates all related documents **within a transaction**.
- During execution, all related documents are **temporarily locked**, but other work in M-Files **can continue normally.**

If the operation exceeds the scripting timeout, the **transaction fails and all changes are rolled back**.

If execution completes successfully, **all documents update simultaneously**.

**Background behavior**

When the user changes the **Project Manager** and clicks **Save**:

- The Project **saves immediately.**
- Related documents are processed **one by one in the background**.
- During execution, only the **document currently being updated is locked**, while other work in M-Files **can continue normally.**

In this mode, the **scripting timeout does not interrupt the entire process**, since each object is processed independently.

**Summary**

| Mode | Object Save | User Experience | Transaction | Timeout Impact |
| --- | --- | --- | --- | --- |
| EventHandler | Waits for rule to finish | UI locked until rule completes | Yes | Rule fails if it exceeds the 90-second scripting timeout |
| BackgroundTransaction | Saves immediately | Documents locked during processing | Yes | Transaction fails and all changes are rolled back if timeout is exceeded |
| Background | Saves immediately | Objects processed one by one | No | Timeout does not stop the process |

**Additional notes**

- Some organizations prefer **EventHandler execution,** because users immediately know whether the rule succeeded.
- Others prefer **background execution**, where processes run without blocking users.
- **EventHandler rules create fewer object versions.** For example, if a Property Operations rule updates the same object that triggered the rule, EventHandler typically creates **one new version**, while Background and BackgroundTransaction create **two versions**.
- In M-Files, the **default scripting timeout is 90 seconds** and **can be adjusted in Advanced Vault Settings.** Increasing the timeout allows longer rule execution but **may increase CPU usage and server load.**