I am build a sharepoint document list that will be queried by a 3rd party app we are building.
The document list will hold around 5-10k documents. I need to tag each document with a related customer ID's (we have thousands of customers). Multiple customers will be tagged against a single document.
I will be querying the document list via sharepoint url to return documents based on customer ID in custom view.
What is the best way to create a one to many relationship between a document and multiple references/ID's?
#user15092184,
You can create a list for the customers, then add a multiple-value lookup column to the document library and references the customer lists.
you can select 'Allow multiple values' to create a one to many relationship.
https://sharepointmaven.com/how-to-create-a-lookup-column-in-sharepoint/
BR
Related
Is it possible to search by invoice number? When I search by invoice ID, I want to display the invoice. The document number is already selected in the search preferences. For example when i search by 2090, I want to display the invoice.
The search in the admin panel only comprises the entities which you see in the drop down. This includes orders, but not documents.
Adding other entities to the admin search is described in the German forum.
You could add a provider for the search using Application.addServiceProviderDecorator.
There is not really a document listing route, as documents are displayed as a part of the orders. So you could reuse the one for the orders and just display the matching orders when an associated document matches. Or you create another listing for all documents.
Another approach would be to extend the matching for orders in the backend and also search for document numbers.
Novice in Sharepoint and looking for some advise.
we are trying to setup a infopath form with the below fields.
ReqID (Autogenerated with a workflow based on ID like Req-1 etc.),
Description,
User,
Date,
Testing,
Tester,
Date
when the user submits the form, we would like to save the information to two separate lists on sharepoint like...
List A - ReqID, Description, User, Date
List B - ReqID, Description, Testing, Tester, Date
Can someone please advise if this is doable without using any coding.
Thank you so much for all the help.
Several possible solutions:
One list:
If it is a matter of hiding clutter from selected users then: create one list for all of the fields and then create two views, one with your first set of columns and the other with the second set of columns. This has the advantage of no duplication of data, and if you need to update the Description column, it only has to be done in one place.
Two lists:
From the InfoPath form, post all of the fields to the first list and create a View that only displays what's needed for the "A" users. Create a workflow that adds a new item to list "B" with only the data needed.
Three lists:
From the InfoPath form, post all of the fields to a master list. Create a workflow that copies selected fields to List A and to List B. This has the advantage of the master list being an unchanged source of the original data for audit or tracking purposes.
Using Web Services
I believe InfoPath can call web services. This will be more like "coding", but you can write data directly to SharePoint lists using SharePoint's REST API.
Im trying to create a Unique sub list within a list in Sharepoint Online (2013).
I realize that sub lists arent exactly possible and you can use lookup fields to attach another list. This doesn't seem like it will work for my situation.
I am trying to have a list item that allows you to upload unique files per list item. For Example:
Reports May 2015
---School.xml
---Food.xml
Reports Jun 2016
---University.xml
---Beach.xml
Each list item will have a set of unique files related to it.The user needs to be able to make the List item themselves (Reports ... in this case), this will of course have other fields and descriptions attached to it (hence the list) and then be able to upload unique documents to that list item.
Im having problems figuring out how to do this in SharePoint. If there is another way to go about this better i am up for it.
You're right - sublists aren't a thing in SharePoint. Reading your requirements, I'm not sure if you need two lists to get what your looking for. Would it be possible to have a single Document Library with a custom field for "Category" or "Report Month". This field could either be a Single line of text field or Choice field. From there you could create a custom view to group by this field and give the hierarchical view from your example.
If you need separate metadata for the grouping/top level, you may need to use Lookups. If I was putting together the solution, I would set up a List and a corresponding Library with a Lookup field to the List. Each of the documents uploaded to the Library would reference the List via that Lookup. To provide an interface for interacting with both within the same view, you'd need to frontend it with some custom code such as a SharePoint-Hosted App.
I am a bit confused about terminology. In SharePoint we have a List and it consists of List columns but I have read in one of the site that this can be meta data too.
Taking an example if we have a SharePoint list and if we have a List Columns with name, Job description, age and Income, will this be termed as column, field or metadata?
If this is metadata then how can you define fields/columns/site column?
You may know that Meta Data is nothing but data about data.
In share point context Meta Data can be used as list column also. Consider any excel documents which are classified using Phase , Category, Document Type etc. So when ever you see these columns you can identify what kind of document it is.
As per my knowledge key words are nothing but taxonomy. By using these keywords you can classify the items.
Site Column is different. Site Column can be used as list column in any list. For eg. Consider the Age. In your site you are using Age column repeatedly in your lists/libraries. So instead of creating Age column in each list you can create only one site column and you can add to required list. In simple words reusable purpose.
Fields are nothing but a columns/site columns. These are related to list.
As Mihir states, the word "metadata" means "data about data". So to have metadata you need to have data. In SharePoint the most relevant example would be documents. Documents are data and you can have data (metadata) about these documents. Mihirs Excel example is an example of this.
Say, you want a document library in SharePoint and these documents have a document type chosen from a list of choices.
To achieve this you need to be able to put a document type on the documents. Since Document libraries in SharePoint is a special kind of list, you can create columns=fields on the list - and the data in these columns becomes metadata for your document.
So on the library you create a field, DocumentType, e.g. as a choice field. The field is setup with possible choices for the document type. So the list fields/columns are used to define metadata on the document(s).
When it comes to pure SP lists it becomes more difficult to talk about metadata. For what is it data about? In case of an employee I don't think you can define it as metadata, expect if you treat the physical person as "the data". However, I don't think it technical make a difference. You have your datamodel of the employees and implement it using SP lists - that's what they are there for!
I have a sharepoint with a lot of documents stored in it. I would like to have different views for these documents. One view would be by "project" to see all related project documents, another view would be "Design Documents" to view all design documents across all projects. Is there a way to do list so that there is only 1 copy of the document?
Ofcourse there is, that's what list view's are for.
You can group, filter and sort items based on various fields.