I have created a SharePoint List (on 365 Enterprise) for logging accidents and incidents in our business. The list is populated using an InfoPath form that presents the user with the relevant fields that need to be populated based on the nature of the incident.

A key part of the process is the generation of a unique incident reference which is formed from: projectID/year/month/day/sequential number

To generate the sequential number I had set the list up with a custom field. On submitting the form, the submit rules would determine the last-used number for that year, increment it and use that as the sequential number for this list entry. A new view of the form would appear, advising the user of their unique reference.

Everything was working fine until the need arose to record the home address and telephone numbers of injured parties. This is personal information which should not be visible to all users of the list. I considered options for making these fields viewable only to the person creating the record in the list, but one of the processes in the case of an injury is to print out the accident form, gain signatures and attach the scanned document back to the injury record. I would therefore also need to hide the attachments or handle them through some other mechanism. The most straightforward approach was to allow individuals to see only the records that they have created in the SharePoint list. Unfortunately this has caused the unique reference generation to fail. Each user can only see their own items and the code will return their last-used number, rather than the last-used number in the list.

I considered using SharePoint Designer workflows to manage the unique reference generation, but there is usually a lag between submitting the form and the workflow running. The reference number needs to be available immediately.

My next strategy was to use a second list, accessible to all, to handle the sequential numbering. I have no trouble bringing in the number currently stored in the list, but I am struggling with getting the list to update.

The second list consists of 3 fields: ID,Title,Tally. I have used the Title field to store the Year Number.

I have created a CAML file and loaded it as a Data Connection:

<?xml version="1.0" encoding="UTF-8"?>
<Batch OnError="Continue">
    <Method ID="1" Cmd="Update">
        <Field Name='Tally'></Field>
                   <FieldRef Name='Title' />
                   <Value Type='Number'>2015</Value>

I have set up a web service (submit data) data source connecting to the _vti_bin_/lists.asmx location of the site and selected UpdateListItems. I have determined the list GUID and set this as the default value of a text field on the main list that isn't visible to the users. This text field is used in the listName setting in the data connection wizard. I've set the update field to /Batch.

enter image description here

I've tried various combinations of settings in the Submit Rules to try to get the value of the Tally field to change, but nothing is working.

Questions: Is it possible to update a secondary list using only OOB InfoPath Rules? I need a single submit button to determine the unique reference and submit all the fields to the main list. Am I even close to the workable solution?

1 Answer 1


It is possible to set up a secondary data source in InfoPath to read/write to another list in your site (https://support.office.com/en-us/article/Add-a-data-connection-to-a-SharePoint-document-library-or-list-3233d77d-95af-4245-a124-dca2f6d5d02e) -- although it would seem that you run the risk of a concurrency issue -- even in your current scenario, since SharePoint does not have a concept of isolated thread-safe transactions, if two users are submitting forms with a second or so of each other, they could both end up grabbing the same number during the time it takes SharePoint to look up the current number, increment it, and save it back. Do your requirements definitely require that the numbers reset each year? If not, a safe implementation would be to append the Item's built-int ID to your generated reference (i.e. projectID/year/month/day/[currentItem.ID]). This would be easier to implement, gaurantee of no duplicates, and would work regardless of permissions. The downside being that your numbers could never be reset back to 1 for each year (unless you created a new list each year).

  • Using the list ID would not be ideal but it would be acceptable. The only difficulty I'm having here is that the list ID is not available until after the item has been created. Is it possible to submit the form, get the ID, write the generated reference back to the list item and display the new view in a single set of submit rules?
    – Gordon K
    Dec 7, 2015 at 16:11
  • That is certainly possible, although you would still need to at least temporarily use a different naming technique to ensure that your Name is unique, before getting the ID to append.
    – willman
    May 26, 2016 at 19:59
  • Another possibility, although I have not attempted this within InfoPath, but the SharePoint REST API has a method I have used from JavaScript to "Reserve" the next list ID so nothing else uses it: msdn.microsoft.com/en-us/library/office/… -- you can use REST services as datasources in InfoPath, perhaps you can grab the ID this way.
    – willman
    May 26, 2016 at 20:01
  • I ended up using the built-in ID in the end. This approach needed me to submit the item, read the ID, update the incident reference, resubmit and change views. It's not elegant and won't reset each year, but it's good enough. My next challenge will be dealing with the 5,000 item issues!
    – Gordon K
    May 26, 2016 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.