How to apply shared rules across multi-client feeds without breaking things

Previously, we focused on getting multi-client imports, permissions, and default templates in place so every new client starts from a consistent foundation.

In this chapter, you'll see how to implement shared rules multi-client feeds rely on, turning your best-performing logic into reusable templates that apply across projects without mixing data between clients.

Key takeaways

• Shared rules let you build feed logic once and reuse it across projects and channels within the same client account, not across different accounts.
• Implement a templatized approach only for the rules that are universally true across all clients, like title length checks, HTML removal, and field fallbacks. Keep margin logic, brand formats, and category exclusions client-specific.
• In Channable, master rule groups run before any channel logic. Set your foundational data hygiene here first, before building any shared channel-level rules.

How to use shared rules to manage multi-client feeds without duplication

Shared rules are feed rules you build once and apply across multiple channels within the same client account. Update the rule in one place and every connected channel reflects the change — no manual repetition, no inconsistent copies.

In practice, agencies use two layers of rules:

The first is a shared baseline logic that applies to all projects and channels, such as title formatting standards, mandatory field validation, and universal exclusions.

The second is a client-specific layer that sits on top, covering exceptions unique to one account's catalog, pricing structure, or channel mix. The shared layer handles the repetitive work. The client layer handles what genuinely differs.

💡 For agencies, shared rules help standardize logic across projects within a single client's Channable environment, not across different clients. Build the shared rules library once per client account, then reuse it across that client's channels.

Let's look at these in detail below.

Decide which feed rules you should set up across clients

The most common mistake agencies make when setting up shared rules is using a templatized approach across clients — copy-pasting shared-rule logic across client accounts without client-specific context. But not every rule behaves the same way when run against different catalogs.

Here are the most relevant shared feed rules for agencies.

💡 If the condition and action apply consistently across multiple projects and channels within the same company, the rule belongs in the shared layer, not across different accounts or companies. If the rule depends on differences in product data, pricing logic, or business requirements within a specific setup, keep it project-specific instead of sharing it.

Feed rules that should almost always be shared

In multi-client feed management, these are rules where the logic is structurally true regardless of which client's data it runs on — the kind your team sets up on every new account, because there's no real reason for it to differ.

The condition and the action are correct for every client using that channel without exception.

For example:

• HTML removal from description fields: Most eCommerce platforms export descriptions with embedded HTML tags that channels either reject or display as raw text to shoppers.
• Universal exclusion logic: Products with no price, no image, or no availability value should never reach a live channel. These are baseline data quality standards, not client business decisions, so they are safe to share across every account without exception.
• Mandatory field fallbacks: When a required field like brand or condition is empty, a fallback rule assigns a default value to prevent the product from being rejected outright. For example, if the brand is empty, set the brand to the value stored in a reference field. The rule structure is always the same; only the fallback value differs per client.
• Title character length checks: Channels like Google Shopping have minimum title length thresholds. A rule that appends a brand name or category value when a title falls short standardizes quality across every account.
• Price formatting and currency standardization: Rules that strip currency symbols, remove trailing decimals, or reformat price values to match what a channel expects are structurally identical across every client exporting to that channel.

Feed rules that should stay client-specific

These are rules where the logic is tied to decisions, constraints, or catalog characteristics that belong to one client and cannot be assumed for others.

For example:

• Margin-based exclusions and bidding signals: One client might exclude all products with a margin below 15% from paid channels. Another might want those same low-margin products included but flagged differently for bidding.
• Brand-specific title formats: Some clients have strict guidelines governing how product titles are written, like brand name first, specific separators, and prohibited terms. A shared title formatting rule built around one client's brand standards would overwrite another client's legitimate format. Title length checks can be shared; title structure rules usually cannot.
• Category exclusions tied to client strategy: An outdoor retailer might exclude their clearance category from Google Shopping during the off-season. A fashion client might exclude a subcategory that consistently underperforms on ROAS. These are account-level business decisions, not data quality standards, and should never be managed as shared rules.
• Custom label assignments for campaign segmentation: Custom labels group products into bidding tiers like bestsellers, high-margin items, or seasonal stock. Even when two clients use the same label field and the same label values, the conditions that trigger them differ enough to require separate rules per account.
• Regional pricing and tax variations: Sharing price logic across clients with different tax and pricing structures is one of the fastest ways to corrupt data across multiple live feeds at once.

How to set up shared rules safely across projects in Channable in 5 steps

Shared Rules in Channable let you reuse the same rule logic across multiple projects and channels, so your team doesn't have to rebuild the same setup every time.

To understand how they work, you need one key distinction. In Channable, all projects sit inside a single company workspace. Shared Rules can be reused across projects and channels inside that workspace, but they cannot be applied across separate company accounts.

This means you can standardize rule logic in a shared environment while keeping each project's product data independent.

That structure is what makes Shared Rules both powerful and risky. One change can improve consistency across multiple projects, or break logic everywhere it's applied.

The steps below show how to set up Shared Rules in a controlled way, so you can reuse logic where it makes sense, without creating conflicts across projects.

Step 1: Build your shared baseline in master rule groups first

Before you create Shared Rules, start with a clean baseline inside the client's own Channable setup.

In Channable, Master Rules are useful for logic you want to apply across multiple channels within a single project.

That makes Master Rules the right first layer for baseline cleanup inside a project before you start reusing channel-level logic more broadly.

Use this layer for rules like:

• Filtering out products with missing core fields, such as price, image, or availability
• Standardizing values across important attributes
• Cleaning or restructuring fields before channel-specific rules are added

The point is to make the source data more reliable before you build anything reusable on top of it. If the baseline is inconsistent, your Shared Rules become harder to trust and harder to scale.

To create a master rule group in Channable:

1. Navigate to Master rules in the left-hand sidebar of your Channable company account.
2. Click to create a new group and name it clearly — for example, Universal Data Hygiene or All Clients Baseline.
3. Build the rules inside the group (up to 30 rules per group, up to 20 groups total).
4. Assign a color to each group so it's immediately clear which master rule logic is active on any given export.

Once created, master rule groups are added to individual exports under the Settings tab of each export.

Not every project needs the exact same baseline, so apply master rule groups selectively. The goal is to standardize what should be consistent, without forcing every setup into the same structure.

Step 2: Create shared rules for channel-level logic

Once your baseline is in place inside a project, the next step is to create Shared Rules for logic you want to reuse across multiple projects and channels within the same client setup.

These are typically rules tied to how specific channels expect data to be structured. The logic stays consistent, even if the underlying product data differs from project to project.

For example, you might use Shared Rules to:

• Standardize how titles are formatted for a channel
• Normalize attribute values into accepted formats
• Clean or restructure fields before export
• Apply consistent inclusion or exclusion logic for a specific channel

In Channable, Shared Rules let you create this logic once and reuse it across multiple projects and channels. When you update a Shared Rule, the change applies everywhere the rule is used — so accuracy matters.

There are two ways to create a shared rule in Channable:

Option A: Create a new shared rule from scratch	Option B: Convert an existing client rule
Go to the Rules step of any channel. Click New rule and select New shared rule. Fill in the rule name (required) and an optional description. Optionally create a label to keep your shared rules library organized. Click Create.	Go to the Rules step of the channel where the rule already exists. Click on the rule you want to promote. Click the Options dropdown and select Convert to shared rule. Confirm the conversion.

⚠️ One important limitation to keep in mind: Shared Rules are not global across all clients. They can only be reused across projects and channels within the same Channable setup, not across separate client accounts.

Step 3: Add shared rules to the right projects and channels

Once a Shared Rule is created, the next step is deciding where it should apply.

Shared Rules do not apply automatically everywhere. You choose which channels use them, and that choice determines where the rule logic is executed. Because any update applies to every place the rule is used, being precise here is critical.

Before adding a Shared Rule to another channel, first check where it is already in use. This helps you understand the full impact of any future edits.

To view and manage shared rules across your client's channels:

• Go to the Rules step of any channel. Click New rule → New shared rule → View shared rules
• Alternatively, hover over any active shared rule in a channel and click Go to main rule

This opens the Shared Rules overview, where the Usage panel lists every channel connected to that rule.

To add a shared rule to a new client's channel:

1. Go to the Rules step of the relevant channel
2. Click New rule → New shared rule
3. Select the rule from your shared rules library

One important limitation to keep in mind: this reuse only works within the same client setup. Shared Rules cannot be applied across separate client accounts or companies.

Step 4: Layer project-specific rules on top

Once your Shared Rules are in place, you can add project-specific logic directly in the Rules step of each channel.

In Channable, both Shared Rules and standard rules live in the same rules list inside a channel. The difference is:

• Shared Rules are reused across multiple projects and channels
• Standard rules are created and used only within that specific channel

This setup lets you apply shared logic first, then handle exceptions without affecting other projects.

Use project-specific rules for:

• Custom title changes for one brand or market
• Project-specific exclusions
• Different fallback values
• Channel logic that only applies to one setup

If one project needs a different version of a Shared Rule, do not edit the Shared Rule directly. Any change will apply to all projects and channels that use it.

Instead:

1. Open the rule in that channel
2. Click Detach from shared rule
3. Confirm
4. Edit the standalone version

Once detached, that rule becomes a standard rule in that channel only.

One important limitation to remember is that detaching is permanent. You cannot reattach that same rule instance to the Shared Rule later. To use the shared version again, delete the standalone rule and add the Shared Rule.

Step 5: Use rule order intentionally to prevent conflicts

In Channable, rules run in sequence from top to bottom. That means the output of one rule becomes the input for the next one. If the order is off, even well-written rules can produce the wrong result.

This matters even more when you combine master rule groups, Shared Rules, and project-specific rules. A rule placed too early can remove products, overwrite values, or change fields before the rules below it have a chance to run.

A reliable way to structure rule order is:

• Master rule groups first: Use these for baseline cleanup at the source level before channel-specific logic starts.
• Shared Rules next: Place reusable channel-level logic high in the rule sequence so it applies consistently wherever that Shared Rule is used.
• Project-specific rules after that: Add these below Shared Rules when a specific project needs an exception, override, or local adjustment.

The main thing to watch is exclusions. If a rule excludes products early in the sequence, those products will not continue through the rules below. So before you move an exclusion rule higher up, check whether any later rule depends on those products still being present.

The same applies to overwrite logic. If one rule rewrites a title, availability value, or attribute too early, the next rule will only see the edited version, not the original one.

Treat the rule order as part of the setup. In Channable, the rules themselves matter, but the sequence they run in determines the final feed output.

⚠️ Watch your rule order before going live. If a shared rule excludes items early in the sequence, no rules below it will run against those excluded items. So check whether any client-specific rules downstream depend on data that those exclusions remove. To reorder, hover over the hamburger icon next to the rule and drag it into position.

Apply shared rules across projects and channels in practice

At this stage, the challenge is how to decide where they should be reused, where they should stay limited, and how to manage them as more projects and channels are added.

Apply Shared Rules only where the logic applies

Shared Rules work best when the logic stays consistent across different projects and channels. If a rule depends on a specific feed structure, a local naming convention, or a one-off decision, it is likely to break or create inconsistencies when reused elsewhere.

For example:

• A rule that removes HTML from descriptions is safe to reuse across most projects and channels
• A rule that sets a default brand value may only make sense for one specific catalog

Both are technically valid rules, but only one is truly reusable.

Test Shared Rules in one place before expanding them

Just because a Shared Rule works in one channel does not mean it will behave correctly in another.

For example:

• A rule that appends "Free Shipping" to product titles may work well in Google Shopping
• The same rule could create clutter or formatting issues in a marketplace feed that has strict title requirements

Instead of applying the rule everywhere immediately, test it in one channel, confirm the output, and then expand to other channels where the logic still holds.

Avoid overlapping Shared Rules that modify the same fields

As your Shared Rules library grows, it becomes easier to create rules that unintentionally conflict.

For example:

• One Shared Rule adds the brand to the product title
• Another Shared Rule rewrites titles based on category logic

If both are applied to the same channel, the final output depends on rule order and can quickly become inconsistent.

To avoid this, keep each Shared Rule focused on one clear task, avoid duplicating logic across multiple rules, and check whether an existing Shared Rule already solves the same problem.

Always check where a Shared Rule is used before editing it

Every Shared Rule has a footprint across projects and channels.

For example:

• You update a rule that filters out products with missing images
• That rule is also used in three other projects where image handling is different

A small change can suddenly remove products from multiple feeds without warning.

Channable provides a usage view so you can see where a Shared Rule is applied before making changes.

Before editing, check where the rule is used, confirm the change works in all those places, and decide if a project-specific rule would be safer instead.

Keep shared rules working as your client portfolio grows

As your client portfolio grows, so does the value of having a repeatable rule setup you can rely on. The shared rules you've built aren't transferred automatically between client accounts, but they act as a proven template your team replicates manually each time you onboard a new client. The challenge at scale is keeping that template current and making sure everyone on your team knows what each rule is for and why it exists.

Audit shared rules frequently to remove outdated logic

A Shared Rule that made sense six months ago may no longer deserve broad usage.

For example, a rule built for an older channel setup, a seasonal promotion format, or a temporary catalog structure can remain active long after the original need has disappeared. When that happens, teams keep reusing logic that no longer matches the current setup.

A regular audit helps catch this. Review which Shared Rules are still actively used, which ones have become too narrow, and which ones should be retired or replaced. This keeps your library focused on rules that still solve repeatable problems.

Standardize naming so teams know what a rule is for

As the number of Shared Rules grows, unclear naming becomes a real operational problem.

For example, a rule named "Title fix" tells your team almost nothing. A name like "Google Shopping title cleanup" or "Availability normalization for marketplace feeds" makes the rule's purpose clear.

If teams cannot quickly tell what a rule does, they are more likely to duplicate logic, apply the wrong rule, or avoid reusing the library altogether.

Separate stable shared logic from temporary campaign logic

Not every useful rule belongs in the shared layer forever.

For example, a temporary rule for a holiday sale, a limited-time promotion, or a short-term stock message may be needed across several channels for a while. But that does not mean it should remain indefinitely in your core Shared Rules library.

As your client portfolio grows, it helps to distinguish between:

• Long-term shared logic that supports the ongoing feed structure
• Short-term rules tied to campaigns, promotions, or temporary exceptions

That separation makes the library easier to maintain and reduces the chance of outdated campaign logic lingering in active setups.

How Channable helps agencies apply shared rules at scale

For agencies, the value of Shared Rules is having a way to reuse rule logic without rebuilding the same setup across every project and channel inside a client's environment.

Channable's AI Product Attributes can automatically extract and generate missing product attributes, such as color, material, and size, from existing feed data. That helps populate the fields your Shared Rules depend on before those rules run, reducing the amount of manual cleanup needed across projects.

Plus, AI Product Categorization helps map products to the right channel categories at scale. That gives your channel-level rule logic a more standardized structure, making Shared Rules easier to reuse across similar setups.

With Channable, agencies have a more reliable system for scaling feed logic.