Hi,
I see from the Release Notes for this week that OTB-I-580 is coming out which allows for DNC on things other than Phone Number (e.g. account number,.)
Now, assuming that this means that the DNC lists will be expanded to include columns to contain this additional information, will the API be similarly updated to allow these additional columns to be accessed?
TIA
I apologize for your troubles; it is unfortunately the stance of our release management team that API details be excluded from the release notes, so this information isn't documented anywhere and won't be in the release notes.
When using the API to create this new type of DNC list, use POST /api/v2/outbound/dnclists as you normally would, but use "dncSourceType": "rds_custom" and specify the contact list column name you want to match against using the (currently undocumented) property customExclusionColumn.
Once you have the list created, use the currently unreleased API endpoint PATCH /api/v2/outbound/dnclists/{dncListId}/customexclusioncolumns to add/remove entries from the list that will be used to match values in the column specified when creating the list.
Hey!
No need to apologize, I can understand why API changes are not included in the Release Notes (which is why I'm asking here!)
I have a project at the moment that is dependent on this functionality, so it's extremely timely and welcome!
I need to be able to store an "additional column" (we won't actually use it for scrubbing, but that's irrelevant) but I will need to add entries to DNC that include values for the columns. You didn't mention the POST endpoint used to append to DNC, but can we assume that this will also allow the additional column to be populated?
The patch method I mentioned above is what you use to add/remove entries to/from the DNC list. The process to populate your custom column in the contact list remains unchanged; manage the contact list entries the same as you've done in the past.
OK, so now I may have an issue....
What if I want to add a row to the DNC table and populate both Phone Number and Custom Column?
If I'm reading the PATCH statements correctly, /api/v2/outbound/dnclists/{dncListId}/customexclusioncolumnswill only add to the Custom Column, whereas
/api/v2/outbound/dnclists/{dncListId}/phonenumbers will add to the Phone Numbers Column only.
How do I submit an update that writes to both columns simultaneously.
For context, we won't be using the extra column to scrub, instead the customer needs to store a reference relating to the creation of the DNC entry.
You don't. You have to configure and update each DNC list individually. But keep in mind that a campaign can have multiple DNC lists associated with it.
Thanks.
So are you saying that a DNC list is either Phone Numbers or Custom Columns? That's a shame - it won't work for my application 
Thanks for the help! I will be submitting an idea 
What's preventing you from making two API requests instead of one?
BTW, new endpoint went out last night: PATCH /api/v2/outbound/dnclists/{dncListId}/customexclusioncolumns
I need the data tied together. I know the Custom Column is intended for scrubbing, but we need to use it to simply store a reference which tracks back to how the entry was added. (The DNC list will be updated from different sources, we need to track which one was used.)
I saw the update to the API, thank you!
Ah, I see. I think there was a misunderstanding about what the new feature is for. It provides a way to avoid calling records on something other than phone number, like "don't call anyone with the name Ed, Edd, or Eddy", by providing a DNC list type that does a simple value match in a column instead of applying phone number logic.
For your case, a workaround could be to use a facade table/list (of your own design and maintenance) that is updated with the phone number and the extra data you're looking for. Then a process can synchronize this list with Genesys Cloud. That would require everyone to interact with the facade list and you wouldn't have tracking if anyone edited the list directly, but it might get you what you need.
Yes, I understand the intended use - it's the same as the feature in PureConnect 
(And, if I'm honest, long overdue!)
I was hoping to re-engineer / re-purpose it to avoid doing exactly what you suggest. The customer doesn't want external data stores and Data Tables are limited in their size (in addition, we would double the number of API calls since we need to update both.)
Never mind, back to the drawing board 
Thank you for responding.