Is there any way to suppress messages after importing into a List that are a result of the 'Another row has already been processed with this key'
I don't think you can simply disable warnings, but could you please advise why you need to do this?
BTW, If this is a result of building a list from the same source as data load (for example data contain periods causing key to be duplicated), a separate upload based on different source selecting unique items could help.
The reason for this is because when end users run a process containing several list import routines, when the confirmation message shows the warnings then they have to open each one to check if there are any errors and 99% of the time it is for the 'Another row has already been processed with this key' type message rather than a 'real' import error as such.
It is a building a list from the same source as data load type of thing, so maybe a unique items selection would be the best option.
Yes that is correct, it is a model that I have inherited and has been in use for some time. Basically there is one import process that pulls in data from the data hub model, this process updates several modules and lists in one process and on the lists it is set to only import the first instance of the list item, therefore we end up with a warning message each time. Usually the end user would ignore those messages but when we have new starters, they think that something has gone wrong with the import so just trying to eliminate that.
I am trying upload data from a CSV with date. For size reasons, I don't want to dimension the module by date but bring it in as a line item formatted as date. The problem is that person that will be doing the upload is in Italy, and their date format is different. When she does the upload, the date gets messed up…
Hi, when I am assigning the account to the territory I am always facing error as below and account never get assigned to the territory , what could be the reason ? When I use same method for unassign it works .
A while back, I shared a pattern for extracting and reporting on Anaplan audit data using a Python project hosted on GitHub. I wrote that during my time on the Operational Excellence Group (OEG) at Anaplan. The Python solution still works, and plenty of teams are running it today. The problem it solves hasn't changed:…