Request a Campaign Trigger and Flow Action across WorkSpaces

[StephenRPew]

Is it possible to to use the Request Campaign Flow Action and Request Campaign Trigger across Workspaces? Example - Create the smart campaign with the flow action in one workspace and the trigger campaign in another workspace?

[David_Gallaghe2 · Accepted solution]

Indirectly yes. Keep in mind that Marketo Triggers are based on logged activities... so just because you do not see something doesn't mean you cannot trigger or filter off of it. 

In the past I have done this a few ways...

Asset Naming, IDs, and delineators

Using List Name and an Appended List ID in the Name

In this case i add the List ID to the Asset name and wrap it in underscores. Then I can trigger anyone who is added to this particular list by using the is added to list Trigger with the List name constrained to CONTAINS "_ST####_".

Using List Name and an Appended Triggering Smart Campaign ID in the Name

In this case i add the Triggering Smart Campaigns ID to the Asset name and wrap it in underscores. Then I can trigger anyone who is added to this particular list by using the is added to list Trigger with the List name constrained to CONTAINS "_SC####_"

Leverage your constraints

Using a trigger or filter with a contains "constraint"

You can aways use any trigger that leverages a "Contains filter" then you can just add the program name, status etc.

The power of is any, is true, is false constraints

If you are using this for scoring and you want to trigger a score based on program success... just use program = any. it will fire regardless of where the program lives.

Net net 

Triggers and filters are based on activity history. Create your constraints with that in mind and you can do almost anything.

[Michael_Florin]

No. It's the whole point of having workspaces that you cannot crossover to other workspaces' assets.

But you can work around that. For instance, you can change a data value with your Smart Campaign in one workspace and have a trigger campaign in another workspace listen to that data value change.

EDIT: I posted before I saw David's post. He's right. You might not be able to reference an asset with "Form is", if that form is in another workspace, but you can use "Form name contains". Same goes for "List name contains" or "Program name contains". Definitely a reason to have solid naming conventions.

[David_Gallaghe2]

---

@Michael_Florin wrote:

Definitely a reason to have solid naming conventions.

---

AMEN and Absolutely

This is crucial to reporting and scalability. This also applies more broadly to tokens, query strings and more...

My favorite, tucking in special values in querystrings, like ... cta=1, cta=2, cta=0... primary cta, secondary cta and bad cta respectively... I use this to skip the whole "url is" or "url contains somelongcrazystring" and for main/primary ctas... plug in URL contains "cta=1".

Great for scoring ... and doing so across workspaces...

Trigger:

visits web page containing cta=1&

Filter:

clicked link in ANY EMAIL

Constrained

• link contains "cta=1&"
• timeframe IN PAST "1 minute"

[SanfordWhiteman]

---

Trigger:

visits web page containing cta=1&

Filter:

clicked link in ANY EMAIL

Constrained

• link contains "cta=1&"
• timeframe IN PAST "1 minute"

---

The Link ID constraint is underused for this IME.

[SanfordWhiteman]

David’s provided some excellent workarounds here! Still, I’d have to question your workspace configuration if you have to do this on a regular basis and cant even lean on Shared Folders.

[David_Gallaghe2]

I agree with @SanfordWhiteman - I would recommend pushing back on the request to get to the underlying reason for the request... in my humble opinion there are only certain programs and triggers you would want to cross the workspace lines, all being operational in nature...

• Lead/Person Scoring
• On-creation processes
• On person "status/stage" change processes
• Segmentations
• Analytics
• Global Lists/Smart Lists/Reports 

Rule of thumb - keep your programs you want accessible to your users in their workspaces, keep those operational items you do not want them to be bothered by out of their workspaces, and centralize, as an admin, your operational day to day.