Set default Email Digest frequency for all members

There is an Email Digest api that you can leverage either via Automations or a Plugin to set digest subscriptions on events like the group being created or a user joining the group.

Automation: https://community.telligent.com/community/11/w/api-documentation/65698/core_5f00_v2_5f00_emaildigest-script-api#Create

Plugin:  EmailDigestSubscriptions In-Process API Service 

When creating an email digest subscription, be sure to run the command as the user who should be subscribing.

Thanks. I assume you are referring to using the following line to create a subscription

$core_v2_emailDigest.Create($context, $contextId, $frequencyInDays)

What would I enter for $context and $contextId?

While $context could theoretically support different contexts, presently its only documented   option is group. So, "group" for contextId and a group's id for $contextId.

The following command doesn't appear to work in an automation:

#set($emailDigestSubscriptionResponse = $core_v2_emailDigest.Create("group", 2, 14))

2 is the id of the group

14 is the number of days

What am I missing?

What isn't working? Is emailDigestSubscriptionResponse null? Does it have a populated Error list? If so, what are the errors? And if not, are any exceptions logged?

$emailDigestSubscriptionResponse is undefined after the statement. How do you specify which user to subscribe to the email digest?

The API uses the contextual user. Reviewing a little closer, it appears emailDigestSubscriptionResponse will be null if the subscription already exists. Can you verify the subscription exists in this case? 

What do you mean by the subscription already existing? There is an email digest listed in the email digests tab of the Settings page, but it is set to 'Not Subscribed' for the user.

I'd try using $core_v2_emailDigest.GetByGroup($groupId) just to be sure.

This is what I get back when I use $core_v2_emailDigest.GetByGroup($groupId) and do a describe.

[EmailDigestSubscription]

• Context: "group" [String]
• ContextId: 2 [Int32]
• DateCreated: 24/03/2021 15:05:46 [Nullable-of-DateTime]
• FrequencyInDays: 14 [Int64]
• Id: 4 [Nullable-of-Int32]
• NextSendDate: 24/03/2021 15:05:46 [Nullable-of-DateTime]
• UserId: 2102 [Int32]

2102 is the userid of the service account.

This is what I get back when I use $core_v2_emailDigest.GetByGroup($groupId) and do a describe.

[EmailDigestSubscription]

• Context: "group" [String]
• ContextId: 2 [Int32]
• DateCreated: 24/03/2021 15:05:46 [Nullable-of-DateTime]
• FrequencyInDays: 14 [Int64]
• Id: 4 [Nullable-of-Int32]
• NextSendDate: 24/03/2021 15:05:46 [Nullable-of-DateTime]
• UserId: 2102 [Int32]

2102 is the userid of the service account.

So it sounds like the automation is running as the service account which would account for how the subscription was seemingly created successfully and retrieved successfully, but just not for the user you want. Is your automation defined to run as server account? 

If so, you may want to uncheck. But if it needs to run as service user for some other permission reason, you can still impersonate a particular API call with  core_v2_widget.ExecuteFile .

My automation needs to run as service user. 

Michael Monteleone said:

you can still impersonate a particular API call with  core_v2_widget.ExecuteFile .

How would I do this?

Could I call a manual automation from my automation to create the subscription? This manual automation would have the 'Execute as the service account' unchecked.

I have figured out how to do it using core_v2_widget.ExecuteFile, thanks.

You would call:

$core_v2_widget.ExecuteFile('script.vm', "%{ RunAsUserName = 'mmonteleone' }")

And then in an automation attatchment, script.vm, all API calls execute as mmonteleone. It's also possible to pass parameters via ExecuteFile, but it gets kind of difficult in Velocity. Honestly, I'd recommend writing automations in the default of server-side JavaScript instead.

So you could call:

core_v2_widget.ExecuteFile('script.jsm', { 
	Parameters: {
		'a': 1,
		'b': 2
	},
	RunAsUserName: 'mmonteleone' 
});

And then in script.jsm, access those parameters:

var paramA = core_v2_widget.GetExecutionParameterValue('a');
var paramB = core_v2_widget.GetExecutionParameterValue('b');