Hilary Stoupa

InfoPath Dev

Hilary Stoupa

  • Content Type Update Issue in SharePoint 2016

    We saw an issue recently updating a content type in a SharePoint 2016 subsite. The error InfoPath returned on publish was "InfoPath has encountered an error. The operation failed. The parameter is incorrect."

    Error Dialog 

    Using Fiddler while attempting to publish, we noticed that not all content types were being returned from the library where they were stored when InfoPath queried for them. Turns out the view item limit was restricting the number of items returned to the query, so the content type we were trying to update wasn't being found:

    Fiddler Screenshot with Item Count parameter 

    Changing the default view for the library with the content type templates to include all items (i.e., increasing the item limit for the view) resolved this, and the content type could be updated successfully. In the SharePoint 2013 environment previously in use, this issue did not occur, so if you recently moved to SharePoint 2016 and have the same error updating content types - increase the default view limit and try again! 

  • FormsViewer & SharePoint List Data Connections

    If your SharePoint List or Library data connection returns an error in FormsViewer with the following text:

    No adapter found for the name <Your Data Connection Name>

    The most likely culprit is your form's compatibility! InfoPath changed the data structure for SharePoint List and Library data connections with the release of InfoPath 2010. Check your form's InfoPath version under Form Options > Compatibility. Set it to Web Browser Form (which is InfoPath 2013) and then walk through the data connection again to update the schema.

  • Why Isn't My Rule Firing?

    This is a question I see in the forums occasionally, and is something that can be confusing for beginners - so I wanted to do a quick rule review.

    Action rules in InfoPath fire when the field they are on changes. So let's look at the following scenario:

    1. You have a field called "Location"
    2. You want to set a field called "Phone" based on the selected Location

    There are several ways you could do this, depending on the structure of your form and your secondary data sources. For example, if Location is a dropdown that is populated from a secondary data source, and you can associate Location to Phone with that data source, you may want to use a default value for the Phone field.

    But you could also use a rule on the Location field to set the value of the Phone field. That rule will fire every time the Location field changes (as long as any conditions are met, of course!)

    So - let's say the location changes from My Office to Your Office. If we have a rule on the Location field to set the Phone field, the rule will fire.

    If the location changes from Your Office to blank, the rule will fire.

    If the location doesn't change, the rule won't fire. (I know, you think I'm stating the obvious - but if you are using helper fields for some logic, and have some rule that sets the field to "true" and then never set it back.... you may be continually setting the field to the same value and not seeing why your rule isn't firing!)

    If the rule is on the phone field, and you change the location, the rule won't fire. I think the confusion here often stems from the rule conditions - novice form designers may think that because a field in the condition changes, the rule will fire. This is not the case - the rule must go on the field that will be changing.

    You can also use default values when you have secondary data sources with the information you need to populate - but be careful! Defaults can auto update, which doesn't always make sense - take the following scenario:

    1. You have an Order form. When the user selects the item, the price field is populated.
    2. If you set the price with a rule (using a value from a secondary data source) that value will be stable - unless the item is changed the price won't change.
    3. If you set the price with a default, and the secondary data source changes, the price could change when the form is re-opened. That's no good, right? When the item was selected, the price was $20. Now, three months later, the order has shipped, accounting re-opens the form and the price changes to $25. Accounting will hunt you down and shout at you.  

     I've got a simple sample form here that might help with the general concepts. Download the file, right click from the downloaded location, select Design to open in Design mode. From there you can preview and try it out!

  • PowerApps User Research Panel

    Have you tried PowerApps yet? Microsoft is looking for InfoPath form designers for their research panel on this exciting new product.

    You can take a survey here to join - learn more about the panel here.

  • Repeating Table Conditional Formatting Issue

    Just a quick post to let you know about an issue I ran across recently.

    I had a repeating table in a form where some of the columns had shading. We decided to remove the column shading and go to an alternate row shading using conditional formatting. I selected the table and selected "No Fill" for the shading, then added a rule for the conditional formatting. Easy, right?


    My conditional formatting never appeared to be applied.

    I reproduced this in a simple form (attached here - save the file locally, right click and select design, then preview and add rows to see the tables). 

    If a table has had its shading set, even to no fill, conditional formatting that should shade the rows won't apply.

    Here is my table where I have not set the shading:
    Table with formatting 

    And a table with the exact same condition on it where I set the shading to no fill:
    Table where formatting is not applied 

    You can recreate your table, or you can fix this in the view files. I had a lot of time already invested in my form design and had a number of tables affected, so there was NO WAY I was recreating them. Save your form as source files, and remove the background color attribute from the table cells:
    View file with background color attribute 

    I know I don't have to tell you to back up your form prior to working with form source files.... 

  • Office 365 & InfoPath Browser Form Limitations

    Since we never know what will or won't work on Office 365 on a given day, I thought I'd outline a few things that we know at this time.

    1. SharePoint Web Services (this includes REST [OData]) are blocked.
    2. Sandboxed forms (forms with code) are slow to load.


  • Cannot Access a Closed Stream

    I had an error on qRules SubmitToSharePointList today that succeeded creating a new item, but failed to update an existing item. The failure error was:

     Exception: Exception from HRESULT: 0x8004304D. Full error node text: Cannot access a closed Stream.

    Since the first thing I did was search online, I want to make sure I blog the resolution in this instance - we were trying to submit data to a column that did not exist. It existed when the mapping was originally created, but then was deleted and replaced with a different column. The error was hard to find because this was a large mapping to a list with a large number of columns, and because the initial submit succeeded, but the update failed.

    So - if using CAML and the UpdateListService to update an existing list item is returning "Cannot access a closed Stream", verify that all the columns you are submitting to actually exist. 

  • Let's Build Something New - Excel Surveys

    While we wait for Microsoft to announce what's ahead (more here)  I think it would be fun to start taking a look at some other tools for capturing data.

    To start with - I'd like to do a quick intro to Excel Surveys. If you aren't familiar, you can find the basics here

    Excel Surveys are created in OneDrive. If you are using Office 365, you already have OneDrive storage available. If not, the free plan includes 15 GB of storage - plenty for a spreadsheet or two.

    Once you have your OneDrive account all squared away, sign into https://onedrive.live.com/ and select Excel survey under the "New" menu:
    New Menu Options - Excel Survey


     A window will open with an area for a title, description, and an initial question:
    Initial Survey Window

    It is pretty and clean - pleasant to use.

    You can easily enter a title and description:
    Enter title and description

     The questions have a little settings icon you can click to edit the question, select a response type, indicate whether a question is required and even add a default answer:
    Question Settings

     Available answer types are Text, Paragraph Text, Number, Date, Time, Yes/No, and Choice:
    Available Answer Types

    Yes/No and Choice will present the user with a dropdown control when they fill out the survey. For a Choice questions you can enter the available choices in the question's settings, like you can in SharePoint List Choice columns:
    Choice answer settings

    The Question Subtitle will show up under the question - you could use that as hint or tooltip text:
    Question Subtitle

    When you are done creating your survey, you can click the Save and View button to preview it:

    Survey Save & View button

    Clicking Share Survey will bring up a page that allows you to create a link to your survey:
    Share Survey Window

    Clicking Create Link unsurprisingly does just that:
    Create Link Window

    Clicking "Shorten link" creates a short link (which again, should not be an earthshattering surprise):
    Short Link


     Anyone you provide the link to can take the survey. Here's what mine looks like:
    Excel Survey

     You'll see I added hint text around the date field - I'd thought that the survey might have a date picker. It did not - but it certainly let me know when I entered an invalid date:
    Invalid date - with text entered

    I'm all XML-y, so I typed in a date in my preferred format:
    Still invalid date

    It was still invalid. I finally entered it as mm/dd/yyyy and my Excel Survey settled down.

    You can't submit with invalid data. If a field marked required is blank, for example, you'll get a warning and the same pink highlighting:
     Invalid - cannot be blank

    Once all data is correctly entered, clicking submit returns a message (which, like so much of what I've shown you thus far, cannot be customized):
     Thanks message on successful submit

    Back at the OneDrive site, you can open the spreadsheet to see the data collected:
    Survey Data

    You can open it in the browser or in Excel. If you want to modify your survey, after opening the spreadsheet in the browser, you can select a number of options under the Survey button in the ribbon:
    Survey button options

    Generally, I can only see this being useful in very limited scenarios. We can't get any data from external sources.  There is some level of data validation, but no rules, no formatting, no real customization. I don't see any way to prevent someone from skewing the data by replying multiple times. However - if you need to collect simple data and need a survey that anyone can access, this may be a tool worth trying.

    If you'd like to fill out my silly survey, just to get a sense of how the various controls behave and overall user experience, feel free to take it out for a spin:http://1drv.ms/1JBtYhr 

  • The parameter is incorrect

    I keep running into the same error on a recent project - the error message is "Some rules were not applied. The parameter is incorrect."

    Message dialog

    InfoPath returns this message when you try to set a value in a data source that has not been queried - so, let's say you have a data connection that does not query on load, and you have rules that execute the data connection that have conditions on them. Sometimes the data connection is executed, sometimes it is not. If you have other rules that may set a value in a field in that data connection make sure you check for the presence of the field or group first.

  • Full Trust Forms - IP Filler Setting

    A qRules user couldn’t open the qRules full trust form for mapping to lists on his computer after installing – he was getting this error:

    InfoPath cannot open form "Form template: file:///C:\Program%20Files%20(x86)\Qdabra%20Software\Qdabra%20Rules%20Library%20(Trial%20Version)\Forms\Qdabra%20InfoPath%20to%20SharePoint%20List%20Tool.xsn The form template cannot be opened, because the system administrator has disabled opening form templates that require full trust."

    He resolved this as follows -

    Open InfoPath Filler > Form Options > Trust Center > Trust Center Settings > tick "Allow fully trusted forms to run on my computer"

    Raise your hand if you didn't know about this setting - I didn't! :-)

  • Pasting Pictures - InfoPath Makes it Easy!

    Short post - but there is something that I know that I thought everybody knew... and it turns out that may not be the case!

    Did you know that you can simply paste pictures into a picture control in InfoPath? This works in 2007, 2010 and 2013 - I don't have a 2003 machine handy to test on.


    You can either right click the control and select Paste or the clipboard icon (depends on version - screenshot above is from IP 2013), or if the control is selected, you can use CTRL + V to paste. Oh - and this can be either for a screenshot on your clipboard or you can copy the picture from your file system.

    Bonus - if the picture control is meant to be used with linked pictures (instead of storing the picture in the form), you can open the picture in your browser, copy it and paste it in. If you check the XML, it will contain the link - the form will display the picture.

    Have fun saving time! No more browsing the file system for you!

    EDIT: Not IPFS (browser form) compatible though - which is unfortunate!

  • qRules SubmitToSharePointList and a Person or Group Column type

    This just came up again here, and I have to admit I have to look it up myself every time it does come up! So - for future reference, if you need to submit data to a person or group column in a SharePoint list, you can submit -1;#userid with userid replaced with an actual user ID. If you need to submit multiple values, separate them with ;#


    And so on...

    SubmitToSharePointList submits CAML to the UpdateListItems method of the SharePoint Lists web service, so if you are submitting using your own custom code, or what-have-you, this will work for you too.

  • Sort Repeating Items On-the-fly - with qRules!

    We recently had a bit of a challenge with one of our internal forms - we wanted to easily be able to re-order some repeating rows, and the approaches we'd tried thus far (using the out of the box InfoPath Move Up and Move Down menu options, little arrow buttons that used qRules to change the value of a field for order and re-sorting, etc.) were not exactly making our collective hearts sing. A bit of a re-think was in order!

    I like the way SharePoint lets me sort columns in a view:

    I can indicate the position I want, and the other columns automatically get their new order number based off the position I've selected:

    Now, I confess - I'm not crazy about a dropdown for this, so I didn't bother with that in this implementation - however, I will address some basic error handling around invalid data entry. The form samples attached to this blog post use a trial of qRules that expires 3/15/2013 - if you are trying this after that date, you'll need to re-inject with a new trial - here's a link to the trial download. Also, the form samples are InfoPath 2007 and are not browser forms - you can try this in IPFS if you'd like, but I am using attributes to hold some data to help with re-ordering, and if you decide to try to implement this in the browser, I'd recommend using elements instead of attributes, since I have seen some event bubbling in IPFS with attributes in the past (i.e. - a changed attribute causing logic on its parent element to execute).

    I'm starting with this form. I've added default data so that I don't have to bother filling it out as I test it:

    The initial data source is relatively simple:

    I like to use an XML secondary data source for logic fields when possible (that is, fields needed for rules, but not really relevant to the form's data) - so here's the XML:

    Add a secondary data connection to your form that uses this XML:

    Here's the form with that added, in case you need it.

    Okay - I just said above that I like to use secondary data sources for fields that are just for logic and here I go breaking my own little rule - but sometimes you have to make exceptions for repeating data because you have logic that needs to be executed on this instance of the group. In this case, I am adding 3 attributes to my Order element to help me in my endeavors:

    Here's the form again with those attributes added.

    Since I'm using default data, I've set the initialOrder for each of my existing rows manually. However, in order to handle for newly added rows, we need a rule to set the Order and the initialOrder when a new row is added. I've added a rule to the repeating Book node for this:

    All the pieces are in place, so let's take a look at the rules and test it out. Our goal is to be able to change the order number for a row and:

    1. Have the other rows Order numbers update as needed
    2. Resort the rows to put them in the desired order

    The first rule I'm going to add is on the Order element - I've named it Trigger Increment, and I'm adding a condition on it - I only want it to run when the EditingOrderPosition field in my secondary FormLogic data source is blank:

    I want this rule to execute only when I change the Order field myself - I'm using the EditingOrderPosition condition to prevent creating a loop, because I know that my rules are going to cause other instances of the Order field to change. So, the first action I'll add to my rule is to set that field's value:

    I am setting it to the count of preceding-sibling Book nodes - I'll use this in another condition later. If your repeating data has a unique identifier, you could also leverage that here - set EditingOrderPosition to the field with the unique identifier and then, in the condition check on the editing attribute, ensure the row does not have the same unique identifier.

    Next, I set the increment attribute to the Order field minus the initialOrder attribute - the initialOrder attribute contains the original value of the Order field, and after the user changes the Order field, the difference between the two will let us know how we need to increment our other fields.

    When the form is running, this is the point where the rule on the increment attribute will fire, so let's go take a look at those and we'll come back to the rules on Order after we walk through the rest of the logic. 

    There are two rules on the increment field - one if increment is less than zero and one if it is greater than zero. I've also included a 2ds field named Sorting in my condition - I use that when I sort the data to prevent rules from firing during the sort (however, I've done a little additional testing, and it appears it is not necessary at this level - only at the Book level if I wanted to prevent that logic from firing).

    The Negative Increment ruleset (runs if the value of increment is negative) looks like this:

    First, I'm setting a helper field in my 2ds to the correct amount to increment the field. Then, since our Order field is less than its initialOrder (i.e., the increment attribute is negative), I need to add one to all Order fields that are greater than or equal to the current value of the Order field I just modified and less than the initialOrder attribute of the Order field I just modified. So, if my Order had the value of 4 (with the initialOrder also being 4) and I change Order to 1, any field with a value greater than or equal to 1 and less than 4 needs to have 1 added to it. Whew.

    In the rule above, I am setting the editing attribute for all fields that meet that condition to true, to execute another rule that increments the row order:

    This adds the current OrderIncrement to the Order - but note the condition to that will prevent the rule from executing if the field is the same that initiated the sequence (mentioned above - if you used a unique identifier instead of a count of preceding-sibling, you'd use that for the condition instead of the count):

    A second rule re-sets the editing field back to false if it is true:

    Back on the increment field, the rules for Positive Increment are similar to the ones for Negative Increment:

    The condition in this case is that the increment attribute is greater than 0 (along with Sorting being blank), and I set the OrderIncrement helper field to -1. In this case, since our Order field is greater than its initialOrder (i.e., the increment attribute is positive), I need to subtract one from all Order fields that are less than or equal to the current value of the Order field I just modified and greater that the initialOrder attribute of the Order field I just modified. So, if my Order had the value of 1 (with the initialOrder also being 1) and I change Order to 4, any field with a value less than or equal to 4 and greater than 1 needs to have 1 subtracted from it.

    Guess what? We are finally back to the rules on the Order field! The remaining actions in the ruleset are pretty straight-forward:

    I set my helper node, EditingOrderPosition back to blank. I set my Sorting node to true (to prevent rules firing during sorting that I don't want to have fire), and then execute a qRules command to sort the rows based on Order:

    Finally, prior to my Trigger Increment ruleset, I have a rule to handle for invalid data. The condition ensures that the user has entered a positive number:

    If they have not, a message is displayed and the Order is set back to the initialOrder:

    Note the use of the "Don't run remaining rules if the condition of this rule is met" checkbox - we don't want to execute the Trigger Increment rule unnecessarily. Here's the final form - I encourage you to download it to walk through the rules, since this blog post is not so much a step-by-step how-to (that would have been mind-numbingly long) and more of a guideline.

    A few more points of interest on this form - so far, I am also able to use the InfoPath Move Up and Move Down right-click menu widgets with this (due to the re-numbering logic on the Book node) and the right-click Insert options also work well - adding a new row in-between existing rows allows all Order nodes to update their values. However, I don't have anything to handle for delete / cut. The logic is somewhat self-correcting - if you delete a row the numbers after it will be off only until a new row is added or the rows are re-sorted, but it is a weakness I wanted to highlight. If you can think of a good way to handle for this, leave a comment and let me know!

    When we use qRules SortTable, the nodes that are being sorted are actually deleted and re-added. I could have used my Sorting helper node to prevent the rules on the Book node from firing - but then I realized I could leverage this behavior to reset my initialOrder attribute as well as handle for user entries that are greater than the number of items in the table - that is, if a user enters a too-high number, the rules on Book that fire during the sorting will correct the number.

    Also - I think this could be implemented without qRules (although I haven't tried) using this method to set the correct editing attributes and manually modifying the view to include xsl:sort and a preserve code block (this won't be browser compatible).

  • qRules RefreshSharePointListItems - Walkthrough for v4.2

    In version 4.2 of qRules, we made a number of changes to simplify the SubmitToSharePointList command. Those changes also impact the RefreshSharePointListItems command - in a good way, I'm glad to say. Like SubmitToSharePointList, you can now run the refresh command for multiple lists with a single rule action, and fewer parameters are required.

    In case you've not seen them, here are my blog posts on these changes thus far:

    In this post, I'll be starting with the form we left off with on the Working With Existing Data post - here's a copy you can use. Keep in mind that my form & mapping is pointed to sites in my environment, so you'll need to modify that, and it is using the current 4.2 trial version of qRules - which expires 9/15/2012. So, you'll want to re-inject with a new trial if you are following this at a later date.

    The Basics

    First off, in case you aren't familiar with the refresh command - let's talk about what it does and how it works. This command is always used with forms that are set up to use the SubmitToSharePointList command where a form field is set to maintain the SharePoint list item ID. The command should generally be run with a rule on QdabraRules data source finshedLoading attribute - a condition should be used so that the rule only runs when that attribute is equal to true.

     When you submit your list items, SharePoint returns the newly created list item ID to the field you have specified via your mapping:

    If you look at your mapping.xml file in a text editor, you'll see the IsId attribute is set to "true":

    On a successful submit, qRules is going to update the indicated field with the value of the associated list item ID - all items in a SharePoint list have a unique integer value in the ID column. By saving that value in the XML for your form, the next time the SubmitToSharePointList command runs, qRules can perform an update on the existing item rather than creating a duplicate.

    The RefreshSharePointListItems also leverages this field - it adds to your form the ability to update all your SharePoint list connected items with the latest data from the list, so your users can update either the XML or the list - they'll stay in sync when your XML is next opened. It also adds the ability to propagate deletes - both from the XML to the list and vice versa.

    This command has two modes - Report and Update. Because the command has the potential to delete or change data, the default mode is Report. That means you have to explicitly state that you want the list data to overwrite your form data.

    A new attribute has to be added to your fields where you are keeping your list item IDs - qRulesLastModified. This attribute stores the date and time the form data was last saved to the list. When the refresh command runs, qRules compares the XML date & time values with the Last Modified column for the list item. If the list item was updated more recently, qRules overwrites the form values, using the mapping.xml to know which column writes to which field.

    If there is an item in the XML that has a list item ID, but can't be found in the list (and the command is run in Update mode), qRules deletes the data from the XML.

    When the RefreshSharePointListItems command first runs, it also creates a list of the items with SharePoint list item IDs currently in the form. When SubmitToSharePointList is next run, if any of those items have been deleted from the XML, they will also be deleted from the SharePoint list.

    Back To Work

    Hopefully that explanation didn't bore you to death or baffle you. But we'll walk through it, and the background above might make what we are going to do seem a little less obscure, okay?

    Since we are picking up where we left off last time, our form already has fields for the list item IDs, and we have our submit commands set up. So the first thing we'll do is add the qRulesLastModified attribute to those.

    When I created my schema, I referenced the ShPId node so that I could have same name in a number of locations:

    Referencing a node is simple - add the node in one location you want it. Then right click the node and select Reference:

    In the next dialog, select the group you'd like to add the field to - simple as that.

    Now the cool part - I just have to add the qRulesLastModified attribute to one instance of my ShPId field, and they all get it:

    Form Changes

    We first need to add an additional data source connection. qRules uses an owssvr.dll data connection to return each item for refreshing in preview or in Filler. If deployed as a browser form, it uses the SharePoint object model - but since we are going to want to be able to preview and test our work, we are going to add an owssvr.dll data connection.

    The data connection is to an XML file, and the URL looks like this:

    Your URL needs to be valid so that you can create the data connection, but qRules will use the server URL from your mapping and the list GUID from your mapping (since, after all, that will be the server and list you submitted to).

    So, in my case, the URL I'll use looks like this:

    The GUID is to my Customers list - again, during the refresh process, qRules will ignore the GUID in the URL and use the one from the mapping file instead, so all that matters is that the URL is valid. You can test your URL in the browser - depending on your browser, it will either return XML in the browser or give you an option to save the returned XML.

    We add a new XML data connection to the form:

    Use your owssvr.dll URL for the location:

    Be sure to select the "Access the data from the specified location" radio button:

    And de-select the checkbox that queries the data on load:

    You'll notice I've named my data connection "Refresh" - name yours whatever you like, but as usual, we need the exact name, including the correct casing, for our command parameters.

    Adding the Command

    Now that we've added our qRulesLastModified attribute and our data connection, we can add the command. We are going to put the rule for the command on the QdabraRules finishedLoading attribute, with the condition that the attribute is equal to true (see *Note* at end for some additional information on this):

    We set the Command node of the QdabraRules data source to the RefreshListItems command:
    RefreshSharePointListItems /dsname=Refresh

    Did you name your data source something else? If so, you'd need to use whatever your data connection's name is for the /dsname parameter. If your mapping data connection is named anything other than "mapping", you'll need to include the mapping parameter as well:
    RefreshSharePointListItems /dsname=Refresh /mapping=MyVeryFancyMappingFile

    Here's a copy of my work in progress, in case you need it.

    As I mentioned earlier, the default mode for this command is Report - this means any changed items will be reported to the QdabraRules Results node. Put that node on your form so you can see the outcome.

    Testing in Report Mode

    Guess what? We are already ready to test! Once you have the form set up to submit list items, adding refresh functionality isn't much work. To test, we'll preview and submit some items to our lists. We'll save our XML that we created in preview, change some of our list items, and then preview again, using our existing XML so we can see what the report result is.

    So, preview your form, create or select a customer, and add some orders and order details:

    Submit your list items, using the submit button, and then use File --> Save As to save the completed XML. Close your form.

    You can open the XML in a text editor, and you'll see that your list items have a SharePoint list item ID along with a value for the qRulesLastModified attribute:

    We need to change some of our new list items from SharePoint - here's my original details:

    And their modifications:

    Set your form template up to preview with existing data, using the XML you saved in your earlier preview (how-to can be found here):

    Remember, we have not included the /mode parameter at this point, so by default our refresh command will only report on changes. Preview your form again, and take a look at the Results field - you'll find text like this:

    Testing in Update Mode 

    Keeping your template set up to preview with your existing data, add the /mode parameter to your command:

    Preview again - this time, you'll have the same report, but your items that you changed in SharePoint should be refreshed to match:

    Euw. Big ugly validation errors - what happened there? Well, my form has a data type of whole number for the Quantity field, but SharePoint is returning the data with decimals - that's okay, I can take care of that with a rule on the Quantity field:

    Preview again, and:


    Leaving the preview open, where the refresh command has already run, try deleting existing items and adding some new ones. Remember, the deletes will occur when the SubmitToSharePointList command is executed, so be sure to click your submit button to run the command. Be sure you remove the path to the XML you've been previewing with before you close your template - otherwise, you will do what I always do - delete the XML and be completely confused when your form refuses to preview.


    That's it! Here's my final form if you want it. The best part of the qRules 4.2 changes, I think, is that if I need to submit data from my form to another list (I'm sure people in your organization never change requirements on you... ) I can export the mapping from my form, import it into the mapping tool, and add the list mapping. I just need to replace the mapping in my form with the new one, and with no other changes, my current submit and refresh commands will now include the new list. That makes changes easier and faster for the form developer, so hooray for that.



    *NOTE*: As you may already know, in InfoPath, rules run before code. qRules is code, of course, but code that is accessed via rules. We want to make sure the qRules code has fully loaded prior to executing any commands. So, if you have a command you would like to run on a form load rule, you should instead run it on the finishedLoading attribute. The qRules code sets that attribute to true when it is fully loaded.


  • qRules SubmitToSharePointList - Walkthrough for v4.2 - Working With Existing Data & Submitting a Single Mapping

    With qRules 4.2, we've introduced a major improvement to the SubmitToSharePointList command - especially if you have been submitting to multiple lists. The first walkthrough can be found here, and then in this post, we talked about how to save attachments with our list items. Picking up where the second post left off, we are now going to modify our form to submit to one of the individual lists we've mapped. Thus far, we've only submitted to all the lists. Also, because I am frightfully lazy, we are going to start pulling some existing data into our form so we can edit it and update our existing customers.

    We'll start with the same template we have been using for the previous two walkthroughs - mine is available here, if you'd like it. Keep in mind that my form & mapping is pointed to sites in my environment, so you'll need to modify that, and it is using the current 4.2 trial version of qRules - which expires 9/15/2012. So, you'll want to re-inject with a new trial if you are following this at a later date.

    Data Connections

    First, we need to add 2 data connections to our form - one that we'll use for a customer drop down, and the other that we'll use to return all the data for a given customer. The first one, which I'll call the CustomerNumber data connection, is to the Customer list, and returns these columns:

    I sorted by Company Name to make the drop down I'll use this data for less annoying.

    Return data on load for this connection only:

    Now, create another data connection to the Customers list:

    Select at least all of the columns that the form is mapped to submit data to. This time, deselect the checkbox to query data on load:

    Form Changes

    In my form, I've decided to let the user choose an existing customer or just fill in the fields if they want to create a new customer. I've added a drop down that is bound to the /my:myFields/my:Customer/my:ShpId field - you may recall from the earlier walkthough that when mapping, we can indicate a form field that will hold the SharePoint List item ID after a successful submit- we are going to leverage this field to allow our users to open a new form and edit existing customers.

    Set the drop down to use the CustomerNumbers data source, with the ID for the value and the Company Name for the display:

    Here's my form up to this point, in case I've lost anyone.

    After the user selects the Customer, we'll need to query the Customers data source for that customer's data and then populate the main data source nodes with those values - this can be done with ordinary InfoPath rules. While this could be done with rules set on the ShPId field the drop down is bound to, that would make things slightly more complex for us - we'd need to make sure these rules don't run when qRules is populating that field. So, for the purposes of this walkthrough, I'm going to add a button and put these rules on the button. However, you have other options - like:

    • Bind the drop down to another field, and execute the rules from that field - be sure you also set the form field for the ID if you take this approach
    • Have a helper field in a 2ds that set when the form is about to execute the SubmitToSharePointList command, and base conditions off the value of that field to prevent execution of rules when qRules sets the ID field for a new item

    For my form - I'm going with a button.

    My first rule action sets the Customers query ID field:

    To the value of the /my:myFields/my:Customer/my:ShpId field:

    Then, I execute the Customers query:

    Now, since the user selected the ID of the customer she wants, I could have returned all the customer data and used filtered XPath to get the values I want - and if you are using SharePoint & InfoPath 2007, this would be the approach you would probably take (or use the qRules FilterOwssvr command to get back just the single record you need). Since I only will have one record in my Customers data source, I don't have to use filtered XPath to populate my other form values. That makes me happy.

    In the rules above, I am setting main data source Customer group nodes to values from my Customers list.


    Time to check our work - preview the form, and select a customer from the drop down - does all the customer's information get populated correctly?

    If not, check and make sure you are returning data to your Customers data source - and here's my form in progress, in case you need to take a look at it.

    Submit a Single Mapping

    Now that we have added the logic to pull an existing customer into the form, we can add a button to save just the user's Customer changes. The big trick here is making sure that in the mapping we have identified a field to use for the ID:

    And making sure we have in our form set that field to the SharePoint List item ID that we wish to update - in my form, I've done this by binding a drop down to the field ( /my:myFields/my:Customer/my:ShpId) and then using a data connection to my target list for the values - so that the user will be picking a valid item ID from the drop down.

    Our original submit command was:
    SubmitToSharePointList /submit=ShPList

    We then added to it for adding attachments in the last walkthrough. I'm not going to be adding attachments here, just editing my existing customer - so I only need to add the mappingName parameter to indicate which mapping I want to submit:
    SubmitToSharePointList /submit=ShPList /mappingName=Customers

    I'm going to add a region to this customer, since it was missing when I pulled his information into my form:

    After clicking my button with the qRules command on it, I can see the region has been added to the customer:

    If you would like to verify that only the Customer is submitted, add an Order and use the command that submits only the Customer data - you'll find the Customer is added / updated and the order is not. If you need my final form, here it is.


    There you have it - you can make this more interesting by allowing the user to copy in Orders or Order Details - using CopyTable or Insert - so those could be updated. Of course, you'd probably be submitting the XML to a form library in a real form - so you would open the form to update the order.

    But what if someone changed the list item? What if you want your users to be able to edit from the form or the list, and you want to keep them in sync? Stay tuned - next up is a walkthrough on the RefreshSharePointListItems command!


    SubmitToSharePointList Walkthrough
    Working with Attachments

More Posts Next page »
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.