Outlook 2013 Rules to Run a Script: Setup and Safety

Yes. In classic Outlook 2013 for Windows, you can create a rule that runs a VBA procedure: add a suitable public procedure to Outlook’s VBA project, then choose Run a script in the Rules Wizard. If that action is missing, Outlook may have it disabled for security; restoring it requires a registry change, so understand the risks before proceeding.

What a script rule does

An Outlook rule checks messages against conditions you choose and then performs actions. A script rule adds a custom action: Outlook passes a matching message to a VBA procedure, which can inspect or modify that message. For example, a procedure could mark a message as important, categorize it, or move it to a folder. It can also carry out more involved processing, but custom code brings additional security and maintenance concerns.

These instructions apply to the classic Outlook 2013 desktop application on Windows. The Run a script action is not available in Outlook on the web or the newer Outlook for Windows, and Outlook for Mac does not provide this Outlook VBA rule workflow. A script rule is also a client-only rule: it depends on the Outlook desktop client rather than being executed as a server-side Exchange rule.

Prepare a small VBA procedure

Before building the rule, add the procedure it will call. In Outlook, press Alt+F11 to open the Visual Basic for Applications editor. In the Project pane, open ThisOutlookSession under the Outlook VBA project, and add a public procedure there. The following example marks every message passed to it as important:

Public Sub MarkMatchingMailImportant(Item As Outlook.MailItem)
    ' The rule conditions decide which messages reach this procedure.
    Item.Importance = olImportanceHigh
    Item.Save
End Sub

The rule supplies the message as the procedure’s Item argument. Keep the procedure public and use an Outlook.MailItem parameter so it can be selected as a rule action. This example changes only a message property; it does not open attachments, follow links, or run files. In the VBA editor, save the project, close the editor, and restart Outlook before creating or testing the rule. Save changes to Outlook’s VBA project when prompted.

For a more targeted action, put the targeting conditions in the rule itself—for example, match a known sender and a phrase in the subject—rather than letting a broad rule invoke code on every incoming message. You can also add checks in VBA, but the rule conditions are usually easier to review and adjust later.

Enable the Run a script action if it is missing

Outlook disables this action in some configurations because a rule that runs code can be abused. If the Rules Wizard does not offer Run a script, first check whether your organization manages Outlook security settings. A company policy may prevent the change, and you should ask the administrator rather than trying to bypass it.

For a personally managed Outlook 2013 installation, the setting commonly used to expose the action is the EnableUnsafeClientMailRules DWORD value under HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Security. Changing the Windows Registry can affect Outlook, so close Outlook first and make a backup or create a restore point if you are not comfortable editing it. In Registry Editor, create the Security key if it does not exist, then create a DWORD (32-bit) Value named EnableUnsafeClientMailRules and set its value to 1. The per-user location is the same for 32-bit and 64-bit Office.

Reopen Outlook and check the wizard again. If the option remains unavailable, the value may be in the wrong location, a policy may override it, or the installation may be managed. Do not download registry files from an untrusted source to make this change. To reverse the change, close Outlook and delete that value or set it to 0, then restart Outlook. Making the option visible does not make scripts safe; it only permits the rule action to be configured.

Create the rule in Outlook 2013

Once the procedure is saved and the action is available, create a rule from the Outlook ribbon:

On the Home tab, choose Rules > Manage Rules & Alerts, then select New Rule.
Under Start from a blank rule, choose Apply rule on messages I receive, then select Next.
Choose conditions that identify the intended messages. For a test, use a narrow condition such as a specific sender or a distinctive subject phrase. Select Next after choosing the conditions and filling in any underlined details.
In the actions list, select run a script. In the lower rule description, select the script link and choose your procedure, such as Project1.MarkMatchingMailImportant. The displayed project name can differ.
Choose any exceptions, give the rule a clear name, review the rule summary, and finish. If the wizard offers to run the rule on messages already in the folder, leave that option off for the first test unless you intend to process existing mail.

Outlook’s wording and available conditions can vary with account and configuration. If you want to test against mail already received, use the Rules and Alerts window’s Run Rules Now option when available, and select the folder and rule deliberately. A rule that runs on existing messages can make many changes at once, so test first on a small, controlled set.

Client-only behavior and rule order

A Run a script action makes the rule client-only. Outlook must be running to process the rule; it cannot be relied on to execute while the computer is off or while only a server-side mailbox rule is handling delivery. This matters if you expect an immediate action on incoming mail when Outlook is closed. In that situation, a built-in server-side rule action may be more appropriate, provided it meets the need.

Rule order also affects results. Outlook evaluates rules in the order shown in Manage Rules & Alerts, and a rule can include the option to stop processing additional rules. If another rule moves or categorizes a message first, that can change what later rules do. Review the order and exceptions when behavior differs from what you expected. A script rule can also fail to behave as intended if its target folder is renamed or removed, or if the code assumes a message property that is not present.

Macro security and safe use

VBA code can perform actions beyond those listed in the rule wizard. Treat a script as executable code, not as a harmless mail setting. Only use code you understand and trust, and avoid procedures that automatically open attachments, launch downloaded files, or follow links. A message can be crafted to match a broad rule, so conditions such as “all messages I receive” are especially risky when paired with custom code.

Outlook’s macro controls are under File > Options > Trust Center > Trust Center Settings > Macro Settings. The available settings determine whether macros are blocked or whether Outlook prompts about them. Do not enable all macros simply to make an unfamiliar script work. If your organization requires signed code or centrally managed settings, follow its policy. The registry setting that reveals Run a script and the macro security settings are related to safe use, but they are not interchangeable: enabling the rule action does not automatically make every macro trustworthy.

When a built-in action is a better choice

Use a standard rule action when it can accomplish the task. Outlook rules can do common work such as moving messages, assigning categories, flagging items, forwarding, or redirecting, depending on the account and rule setup. These actions are easier to inspect and generally avoid the extra VBA and security setup. For instance, if the sole goal is to put invoices from a known address in a folder, a sender condition plus the move-to-folder action may be enough; a script adds no benefit in that case.

VBA makes sense when the required operation is not offered as a standard rule action, or when a specific transformation needs custom logic. If you need the processing to happen while Outlook is closed, investigate a service-side workflow appropriate to your mailbox, such as a supported Exchange or Microsoft 365 automation option. That is a different setup from an Outlook 2013 VBA rule, and availability depends on the account, services, and permissions involved.

Common troubleshooting checks

The script is not listed: Confirm it is a Public Sub in ThisOutlookSession, takes one Outlook.MailItem argument, and that the VBA project was saved. Restart Outlook after editing.
Run a script is absent: Check the Outlook 2013 registry path and DWORD spelling, restart Outlook, and consider whether policy controls the setting. Do not modify a work computer against your administrator’s instructions.
The rule does not run: Verify that the message meets every selected condition, that the rule is enabled, and that Outlook is open to process client-only rules. Check exceptions and rule order too.
The rule appears to do nothing: Temporarily test with a harmless, visible change on a message you control. Confirm the chosen procedure is the one the rule calls, and inspect the VBA code for errors. Avoid testing on a large mailbox.

Keep a copy of the original code before making changes, and document what the rule matches and what the procedure changes. If you remove the rule, also review the VBA project and registry value so that code or a relaxed security setting is not left behind unintentionally.

Frequently Asked Questions

Can an Outlook 2013 script rule run when Outlook is closed?
No. A Run a script rule is client-only and needs the Outlook desktop client to process matching messages. It is not a substitute for a server-side mailbox rule.

Why is Run a script missing from the Rules Wizard?
Outlook may hide or disable the action because it can execute code. In an unmanaged Outlook 2013 setup, the EnableUnsafeClientMailRules registry value may restore it; organizational policy can prevent this. Treat the change as a security decision, not a routine fix.

Can I use this method in Outlook on the web or new Outlook?
No. This procedure uses the classic Outlook 2013 Windows VBA project and its Rules Wizard. Outlook on the web and the newer Outlook for Windows do not run this VBA rule action.

Do I have to create a macro in a separate file?
No. The rule calls a public procedure in Outlook’s VBA project, typically stored in ThisOutlookSession. Save the project and restart Outlook after editing so the procedure is available to the rule setup.

Is a script rule the same as an Outlook macro?
It uses VBA code, but the rule is what determines which incoming messages are passed to the procedure. Macro security still matters, and the rule’s conditions should be limited to messages that genuinely need the custom action.

Try it: the Date Difference Calculator: days, months, years and weekdays between two dates, with the DATEDIF formulas.

More in How-to basics

Sources: Function behaviour and menu paths: Microsoft Support documentation for Excel. Method & sources

Spotted an error in this guide? Let us know.