I have just started to experiment with InfoPath and see some advantages of using the lookup to a SharePoint list for a dropdown list, etc vs a static list in the form itself. I wanted to ask what people think of making a General site where I would create some common lists that are likely to be needed on many different forms, eg instead of repeating these lists on numerous sites?

1. Months - Jan, Feb, Mar,...
2. Dept - Accounting, Sales, HR,...
3. Position - Student, Manager, Partner,...
4. etc

Anything that was more specific to the form could be stored on the site where the form is stored? Does anyone see this as a good idea or are the pitfalls I'll get myself into by doi

That is a very common approach. If you have common lists of data that are used acrossSite Collections, a Term Store would be a great place to store them. If you have a lookup list that is used in many locations within a single Site Collection, then Site Columns are a great way to store/access it.

I think most of us do this as a matter of course, it makes it possible to manage a form without code changes.

2 tips:

1. Use moderation, you don't want too many 'call backs' to sp lists in your form, there is a boundary for callbacks in infopath.

2. Start early in connecting to source webservices(with w/out BCS) from original systems like HR for lists like Dept, position, etc... That way your systems can be kept up to date automatically.

• Marked as answer by Stunpals 13 hours 47 minutes ago

Thank you both for the feedback.

@SharePointShare, I am not sure what you mean by "Start early in connecting back to webservices..."?

I am just working on my first form, an Expense Claim form and this came to mind as I tested things out.

SharePointShark means that if you have a different source of record -- such as an HR System with official titles, to start using that as the source of your data (instead of re-creating it in SharePoint). The feasibility of this really depends on how open/flexible those systems are and the size / scale of your company.

For now I was only planning on a few basic lists that I see being common on other forms, eg Months and I was going to create a new Site with a few of these lists so I am not recreating them.

At this point I am not planning on connecting to other DBs but will keep it in mind should I need that data.

InfoPath solutions start to evolve and multiply pretty fast after you get going.

They are not, however, easy to update safely (depending on how you build them with libraries, workflows, views and available off hours).

Connecting to source data like an HR feed is good to start now as opposed to having to go in and update 15 forms in a few months.

I think most of us do this as a matter of course, it makes it possible to manage a form without code changes.

2 tips:

1. Use moderation, you don't want too many 'call backs' to sp lists in your form, there is a boundary for callbacks in infopath.

2. Start early in connecting to source webservices(with w/out BCS) from original systems like HR for lists like Dept, position, etc... That way your systems can be kept up to date automatically.

• Marked as answer by Stunpals Friday, January 31, 2014 10:09 PM