Can you suppress the creation of duplicate list items through a sharepoint workflow?

Question

I am trying to add logic to a workflow that will check for the existance of a oarticular data item before writing a new record (check to see if what I am about to write already exists, if so don't write it).  Can this be done with SharePoint designer?

Answer 1

hi tony,
i am also facing the same problem, if any item is adding to the list, need to check whether it is already added in the list.

but i am using visual studio 2005.

if you get solution, please let me k now.

thanks

Answer 2

Tony:

 

You can use the Set Workflow Variable Action to perform a lookup against the list.  When you define the workflow lookup, specify the field and value you want to find and store it in the variable.  Later on (in another step), you can check the value of that variable.  If it has a value, then a matching item was found in the list.  You can then react accordingly.  The only problem may be that the item is already created when the workflow runs and so you would have to then delete one.  This could get dicey.

A better solution would likely be an event handler for the ItemAdding event.  Unfortunately, this cannot be done in SPD.

 

-Dave

Answer 3

Praveen:

 

You can use either  the SPQuery object or the SPSiteDataQuery object to check if a matching item is in the list already. 

 

However, you'll have the same problem as Tony in that by the time the workflow fires, the item is already created in the list so you'll have duplicates (potentially) and wil need to figure out which one to delete.  The good news for you is that since you're using Visual Studio, you can do what you need with an event handler.

 

Dave

Answer 4

nice dave,  but i need to check this condition before item was created in the list, i need some process from u, how to do it?

thanks

Answer 5

Praveen:

 

Same links about Event Handlers as I gave for your other post...

 

http://www.sharepoint-tips.com/2006/08/bad-news-synchronous-list-events-bug.html

http://blah.winsmarts.com/2006-7-Sharepoint_2007__List_Events_Practical_Example__Creating_a_rigged_survey.aspx

 

 

Dave

Answer 6

Thanks Dave.  That did the trick for this instance.  Seems to be a bit of a work around but I can live with it as long as it doesn't affect performance.  I was actually able to keep the workflow from creating a new list item by checking the variable prior to actually creating the item as a condition.  It seems to be working fine but I have only had a chance to do minimal testing at this point.

 

Thanks for the help!

 

T

Answer 7

Hi Tony E,

I've the same problem, I need also a solution to check certain fields of duplicate items. I tried the steps from Dave but something is still wrong, it doesn't work for me yet.
Can you explain a little how you've created the workflow steps, perhaps with a screenshot?

regards,

Sarge

Answer 8

I did something similar:
Conditions:
If ListName:Column1 equals ListName:Column1 (CurrentItem)
 and Column2 (current item) equals ListName:Column2

Actions:
 Delete item in ListName



This doesnt work... It somehow always finds a match. Im assuming that since the item is already created, then current item column1 and ListName: Column1 are referencing the same row, hence it always deleted the row even if there was no duplicates. What am I doing wrong?

Answer 9

I know I'm a little late for this answer, but it can be done using SharePoint Designer and a worflow.

Set the worflow to run when an item is created:

Then we want to compare what we know are unique identifiers (ID).

If ID not equals to FullListName(Not The Current Item).ID 

 //lookup the list item/columns you know will be duplicated

where FullListName.commonfield = CurrentItem.commonfield

then Delete Item

So this will allow the first instance of the item to be created, but will then delete any duplicates because the unique ID field will be different.

Answer 10

tmcall, could you explain this in more detail, maybe step by step?

When I attempt this in SPD, the look-up just refers back to itself.

I'm attempting the same objective as above: keep the first instance of a type of item (based on a column option) then deleting any duplicate entries that follow which match this column option.

The current workflow I am working with is initiated when an item is created:

Step 1
if field equals list:field
    and ID not equals list:ID

Step 2
delete item in list

This workflow above simply deletes every new item that is created, rather than maintaining unique items and deleting duplicates.

Can anyone help out?? Unfortunately I'm limited to SPD--I have no other programs at my disposal.

Answer 11

Again, I'm probably too late to help with this, but I've been scratching my head for a while with a similar issue and have come up with a workaround that I can live with at least. I hope it helps somebody

My workflow is not designed to immediately delete a duplicate, rather flag to the creator of the record that a duplicate exists (in this case in the "Full Name" field).  However it could easily be modified to run a delete record action.

Unfortunately it involves the use of creating an additional column which in itself stores duplicate information, however this column can also be useful for other workflow tasks, particularly logging.

What you need to do is create a new column called "Full Name (copy)".  This column will contain a copy of what is in the "Full Name" field, however it will only be populated after your duplicate checking workflow has run.  This means you can compare the "Full Name" field in your new record, with the "Full Name (copy)" field of existing records.  If they match then you can then trigger an action.  If not then you can stop your workflow.

Step by step, this is what I did:

1 - Create a new column called "Full Name (copy)"
2 - Create a workflow to run when a new item is created
3 - Specify the workflow criteria as follows:

- If Full Name not equals Contacts:Full Name (copy)  (where contacts:full name equals current item:full name)
- Set Full Name (copy) to Contacts:Full Name
- then Stop the workflow and log "no duplicate detected"

Else

- If Full Name equals Contacts:Full Name (copy)  (where contacts:full name equals current item:full name)
- Email Contacts:Created By
- then Log "Duplicate name detected - email sent"
- then Set Full Name (copy) to Contacts:Full Name

Basically this checks to see if the "Full Name" field in your newly created record matches the "Full Name (copy)" field in any existing records - ignoring your new item as the "Full name (copy)" field will still be empty.  If there is no match, it ends the workflow and then sets the "Full Name (copy) field" in your new record to the "Full Name" value.  If it does match another record it sends an email to the creator of the record telling them that a potential duplicate exists and it should be checked.

As I mentioned, creating "(copy)" fields are useful to log any changes in your database.  You can create a separate Logging list which can record changes to the main field value by comparing it to the (copy) value.  This is an easier way to track your changes than using versioning.

 

Answer 12

Hello Everyone,

I was able to stop duplicates from being created by the following the following four steps in my workflow:

Step 1: Set the CustomSearchString and store in variable 
if [CustomSearchColumn] is empty
Store Build_CustomSearchString in Variable:CustomSearch

Step 2: Check for Existing CustomSearchString in List
If Variable:CustomSearchString = List:CustomSearchString
Delete item in List

Step 3: Update CustomSearchColum in current item
Set CustomSearchColumn to Variable:Custom Search

Notes:
Step 3 is what keeps the items from being duplicated because once the workflow checks for duplicates, it stores a custom column with information that it will use later to search for.

Answer 13

Nice one Danbert, I got this to work nicely. My list was a test results list, the idea was to create a new record if one didn't already exist; and if a record did exist, update the status and test score - thereby keeping the list to one row per user per test.

Very helpful, cheers

Answer 14

This one worked perfectly for me. Thanks tmccall.