Quick(?) question about the DELETE /api/v2/outbound/campaigns/{campaignId}/progress action. I created a process to delete Campaign contact list records/members at the end of the day, and refresh the list with the current day's calls in the morning. I had planned for a scheduled Campaign to treat the updated list as 'new' and go ahead and make the calls.
Based on my testing, and the topics around 'DELETE /api/v2/outbound/campaigns/{campaignId}/progress', it seems as though I need to trigger this action in order to restart the campaign for the new list, As far as timing goes, I would do that after reloading the Contact List with the new contact/members each day (for a daily campaign). - Is that correct?
Hmm -- I see on the Campaigns overview page that when I (think that I) called DELETE on my campaign progress that the dialing progress reset to , as opposed to 1/1 or 3/3 (these are still in the testing phase, mind you.) That's great.
The campaign I reset was already scheduled to run (and had run successfully); I was hoping that hitting [reset] on it would immediately(?) result in the calls going out again, but they did not.
Now, I did not refresh the Contact List this time, so the contacts still have the dialing status information from the previous go-round. I'm going to go back now and
Clear the Contact List
Restore the list with new members
Reset the campaign again
Bother - based on Recycle Campaigns via API Call, I thought 'recycle' would kick off a new round of calls on an existing, scheduled campaign. I went through the steps above ^, removing all of the current Contact List entries, adding new entries, and calling Delete on the Campaign progress, and with my number associated to the new Contact List entry, I did not receive a call.
Does a Campaign have to be manually started, or associated to a new Schedule, every time it needs to run?
Still hoping for a resolution to this that does not involve manually scheduling Campaigns, each of which runs every weekday, in order to have recurring outbound calls.
Essentially, looking for a 'call every Mon/Tue/Weds/etc. at 8:30 a.m. until specified date', like scheduling a meeting.
I've discussed this with the outbound dev team and this boils down to the campaign's state. From your description, it sounds like the campaign had completed when you added numbers and recycled (the DELETE request). The missing piece here is understanding that recycling does not alter the state of the campaign. The best practice for managing your call list is:
Stop the campaign (COMPLETED is ok too)
Update call list as desired
Recycle the campaign
Start the campaign
Step 1 is optional, but you run the risk of making changes that interfere with or get overwritten as calls are dialed. An amusing analogy from one of the devs was "doing that is like trying to transfer passengers between planes while they're in the air." It's possible, but there are risks involved.
Makes sense, though I don't see any API methods for the Stop() or Start() processes; those would need to be manual, then?
The plan is for campaigns to start in the morning/early afternoon, and for the update/recall process to occur at night/early morning, so there shouldn't be any passenger free-fall involved.
But though the call list will change, the schedule should not, and it's going to happen every weekday, so being able to start/stop via API is key.
I'm getting a status code 400 on my campaignStatus update, sending up only
{ "campaignStatus": "on"}
in the request - I have the list of Campaign properties that can be set, but I don't want to inadvertently set an existing value incorrectly if I can safely ignore it. Are there some properties that must be included, or must I pass along everything (which means retrieving it all first, as there are multiple campaigns)?
Updated my process to GET, modify the campaignStatus, and PUT. I've obfuscated the IDs here, but otherwise this is body of my PUT request (still returning Bad Request):
Looking at the definition for the PUT call to update a campaign, the description for CampaignStatus is
campaignStatus( string ): The current status of the Campaign. A Campaign may be turned 'on' or 'off'. Required for updates.
I've been validating setting the campaignStatus = 'on', and (since my phone number is the only one listed) I begin receiving the calls. That's good, because that's how I am planning to kick off the campaigns once I re-load them with updated Contact information.
I'm also planning (and have validated) resetting the contactList, removing all of the contacts that have already been called, in preparation for the load ^ process. That works as well.
Earlier, the suggestion was made to make sure the Campaign had completed, or was stopped, before updating the associated contactList. I expect that the day's campaign calling will be well over by the time I want to make either change, but I've found that making the PUT call with campaignStatus: 'off' is just as effective at re-starting the campaign as marking it 'on'.
So it appears that touching the campaign in any way using PUT /api/v2/outbound/campaigns/{campaignId} will cause the campaign to begin outbound dialing.
This is not throwing an error - the request/response appears to be going through; the campaignStatus, however, is not reflecting the value that I'm sending over.
Hi Duncan,
I'm a member of the dev team for outbound dialing.
I see no evidence in our logs of any campaign status changes like the ones you say occurred, assuming you're using the same campaign whose ID you shared earlier in the thread. While a user can only make an update to turn a campaign on or off, the full campaign status flow is:
OFF or COMPLETE
-> ON (user-initiated, PUT with a status of "on")
-> COMPLETE (system-initiated, when there are no more contacts to dial) or
-> STOPPING (user-initiated, PUT with a status of "off")
-> OFF (system-initiated, once the campaign is ready to turn off)
A user update with a status of off should never cause the campaign to turn back on.
I've found that making the PUT call with campaignStatus: 'off' is just as effective at re-starting the campaign as marking it 'on'.
Can you describe the behavior you saw when you made this update? It may have been that the campaign went into stopping but had grabbed some contacts from the updated list before its state changed. When making the API request to turn off the campaign, I recommend waiting until a GET request to the campaign returns a status of off (or you can listen for notifications on the v2.outbound.campaigns.{campaignId} channel of Carrier Pigeon, if you're familiar with it).
You know, there's nothing so refreshing as digging into the fine details of a thing, and ... finding the hard-coded fragment that ignores the value being passed in and substitutes 'on' in all cases.
Thank you for being the sounding boards Sean, Tim. argh
