Capping Marketo User privilages - Email sends

[Juhoyos]

Hi Marketo Users

I was wondering if there is a way to cap the number of emails a user can send.

For example, The corporate team can send emails to 100.000 people per email program, region 1 can send 20.000, and region 2 can send 30.000, and so on...

We've been playing around with the smart campaign restriction limits but it's not quite what we want to do. Our biggest pain point is the email programs. If you put a cap on the smart campaign limit that is too high (100.000), the regions with fewer people can potentially send emails outside their region. If we cap too low (20.000), corporate needs to create 5 versions of the emails to be able to send 100k 

Any way we can modify the admin section with code? 

We do not want to change our practice and start sending emails blast (email programs) as default programs using batch campaigns and overriding the limit. 

Any suggestion anyone???

Sandy, please help 🙂 

[SanfordWhiteman · Accepted solution]

It seems like we’re chasing another problem, not really the size of the send.

Are you trying to use “size of audience” as a proxy for “probably sending to people outside of your allowed region”? If so you should be attacking that problem directly, for example via partitions.

[Juhoyos]

Thanks Sandy. This is really helpful

[SaloniMadhok]

Hey 

One option to consider is creating custom fields in Marketo that designate the maximum number of recipients allowed for each region. Then, you can use smart campaigns with filters that check the recipient's region before sending an email. E.g: if the recipient's region is region 1, then the email will only be sent if the number of recipients is less than or equal to 20,000.

Regarding modifying the admin section with code, I am no expert in that, so we can wait for someone else to pitch in. 

Hope this helps. 

[SanfordWhiteman]

The idea is you can't make people use your particular set of filters and procedures. If you could, you wouldn't need administrative controls.

[Juhoyos]

Thanks Saloni, this is a great idea 

[Darshil_Shah1]

I liked the idea of creating partitions and mapping them to the correct WS, but I understand that creating partitions may not be possible due to business requirements not aligning with how partitions function.

Creating a custom field could be a solution, but IMO it's not as tight of a solution as the solution involving partitions, as users could still process people that they shouldn't be processed by just forgetting to include the filter for it. Moreover, creating and managing the custom field so it reflects the correct value would need an operational campaign (preferably trigger) setup. Creating segmentation is another loose solution, where-in you'd not have to create operational campaigns like the custom field solution, but it also has the same vulnerability where-in people are still able to process people in case they don't include the filter in the campaign's smart list.

Also, I don't think it's really possible to enforce any sort of capping on # emails a user could send/process people using code in the Admin. If partitioning is not going to work, then I'd advise you to enforce some additional steps in your process to validate the audience before users could activate the campaign, or if that's not possible you could let only an authoritative user activate and schedule the campaigns and have the rest just build them (you could always create and assign users a role that does/doesn't have rights to activate/schedule campaigns).

[SanfordWhiteman]

If this became an overriding concern I would think about a marketing orchestration platform (Jeto et al.) where the people you don’t trust don’t even log into Marketo directly (or they can log in w/limited privileges but the dangerous tasks have to be done through the platform).

[James_T_Fletche]

@Juhoyos 

The way we've seen this handled by other global organisations is to build the marketable lists for the marketers so they have a specific audience to use or "filter down" on. Much as @SanfordWhiteman says the other controls are Partitions which can sometimes add more complexity depending on your instance set-up.

We also have some organisations where we've developed custom permissions roles & permissions that means they can't approve a program, this again to previous comments is then an administrative overhead, but could reduce the pain.

Cheers, J.