They look similar at first, and it is easy to assume one covers the other. They do not. They check different things, at different points in the process. This article explains what each one does, when to use it, and how to decide.

If you skip this step, Weflow logs everything it can match to a Salesforce record. That leads to a few problems:

Noise in the CRM.
Internal threads, vendor invoices, newsletters and calendar spam all end up on account and contact timelines. Reps stop trusting the activity history because they have to scroll past clutter to find the real conversation.

Privacy and compliance.
Some conversations should never sit in Salesforce. HR emails, legal threads, personal addresses, anything covered by an internal policy. Filtering keeps them out from the start rather than cleaning up later.

Reporting accuracy.
If activity counts include automated notifications and internal chatter, your engagement metrics are inflated. Filtering makes activity data mean something.

API usage.
Every logged activity uses Salesforce API calls. Logging things nobody needs is a waste of your org's limits.

Set this up once during onboarding and it quietly works in the background from then on.

What it checks: the email address itself.

When it runs: first, before Weflow does anything else. If an address matches, the email or meeting never reaches Salesforce at all.

This is the blunt, fast filter. It does not care what account the email relates to or what stage the opportunity is at. It only looks at who is on the thread.

Domain exclusion costs nothing in performance, so you can be generous with it. There is no practical downside to a long list.

It matches on the address only. If a contact record in Salesforce carries an address you have not excluded, mail involving that address will still be logged.

What it checks: Salesforce field values.

When it runs: After Weflow has matched the activity to a record. Weflow finds the account, contact or opportunity first, then checks your rules to decide whether to log it.

This is the precise filter. Use it when the decision depends on what kind of record the activity belongs to, not who sent the email.

You can use any field the connected Salesforce user can see. Picklists work best. Long text fields are not supported, because Salesforce cannot filter on them.

There is a limit of ten custom rules.

Each rule adds an API call per logged email or meeting. Ten rules on a high volume org adds up, so use them where you genuinely need the CRM context and leave the rest to domain exclusions.

A shortcut inside Custom rules. Turn it on, add a value like google, and Weflow will skip any record whose company name, email domain or website field contains it. One entry covers every domain variation and spelling, across the objects you select, without spending one of your custom rules on each.

A simple test:

If you can describe what you want to block by who is on the email, use domain exclusion. "Don't log anything from gmail addresses." That is a domain exclusion.

If it depends on what the record looks like in Salesforce, use a custom rule. "Don't log anything on partner accounts." Weflow has to find the account and read its Type field first, so that is a custom rule.

When both would work, choose domain exclusion. It is faster, cheaper and simpler to maintain.

Teams sometimes add a domain to the exclusion list, then find related emails still appearing in Salesforce. Usually one of these is the cause:

If you want to block a whole company across every domain variation it uses, a custom rule on Account Name is often the cleaner fix.

Both live in the Admin Console, under Activity Capture.

Changes apply to activity captured from that point onward. If you need already logged activity removed, or a re-sync after changing your settings, contact Weflow support and we can run that for you.