I am developing Leave Management System in SharePoint 2013. Employees can apply for leaves and Manager can either approve or reject it.
I have accomplished this by creating a new list - "Leaves" and starting a workflow when a new item gets added. Workflow sends an email to Manager and creates a task item for him to be able to approve or reject it.
However, I would like to know if this approach is preferable in real time scenario. Suppose for organization of 500 employees, can a single list hold so many records for all employees. What are possible ways here to utilize the features in SharePoint and also create a scalable application.
Also, I am also planning to develop a new Add-in in SharePoint 2013 since for applying new leave, we need to display additional information such as available leaves and do some custom validations which are not provided by default SharePoint list. I will be adding the new item to the SharePoint list from the custom developed page so that the workflow still is intact and I am still utilizing out-of-box SharePoint features. Is this the way to go for enterprise level application or there are any other alternatives. Please suggest.
SharePoint Lists are capable of holding that much data. I don't see a problem if you use a single list to hold leave request of 500 employees.
Assume a worst case scenario that all of the 500 employee apply 25 leaves individually in a year, then the item count would be (500*25= 12500) which is not bad.
You will need to take care of the List Threshold error, because data is greater than 5000. For this you can create views which always bring out results less than 5000.
Now lets say you have plan for 5 years, so each year you will add 12500 items which at the end of 5 years will be 12500*5 = 62500 items
Here you can think of 2 options
You can create a list for each year, i.e. Leaves2016, Leaves2017 etc.
In a single list create folders of year, and inside them add all leave datas.
Note: The only major thing you need to take care of List view threshold problem. Which can be tackled with intelligently designing
views
For your second question.
I agree that the OOB SharePoint List form will not cater your requirements. So creating a custom page an add in or something else is a way to go. As far as your data is getting inserted into a list and eventually activating a workflow there is no harm in it.
Related
I posted this question on Stack Exchange here: (https://sharepoint.stackexchange.com/questions/249418/filtering-sharepoint-list-by-another-sharepoint-list), but just realized I should have posted it to Stack Overflow instead. Hope it's not bad form to cross-post (I'll add a link to this post in the other post).
I've been searching the forums and doing research online with no luck- apologies if this has been answered before.
I have a list with several thousand items in it. I often receive bulk update requests where I need to update several hundred of these items at a time (let's say for this example that we're using a field called "Case ID").
Here's what I've tried:
Searching cases individually, or up to three at a time in datasheet view; this is not time effective
Exporting the list and manually manipulating the data in Excel, then pasting in (and writing over) the data in the column that needs to be updated; this approach is not user friendly, is not necessarily time effective, and has potential side effects (causing errors for users currently modifying items that I am changing in bulk)
Lastly- I know I can create custom views that isolate this data; the problem is that the lists of cases I need to modify generally do not have enough commonalities to isolate them using the view filter logic
So- my guess is that I need two lists, likely connected with a web part. The first list would exist solely for the purpose of querying the second list. I would enter the Case IDs I wanted to filter by in the first list, and the second list would filter to show only the Case IDs in the first list. All items would be deleted from the first list between queries.
I'm not married to this approach- it's just my best guess. I'm open to creative and alternative approached, but the final process needs to be user friendly (business partners will be using it).
Does anyone know how I can accomplish this? I've tried to get something implemented several times over the past few years and have never been successful; posting here is my last resort before I throw in the towel.
I have SP 2013, and have SharePoint Designer; please let me know if I need to add any other information.
Thanks in advance for the support,
Chad
I'd suggest to create a JSOM application that will do all updates. It can query only items for update and do item-by-item update.
I'm creating three approved software lists for my company with SharePoint. One is the general list for all associates the next is the restricted list which will contain software like wireshark that only certain people should have access to and the last is the master list which will be a combination of the other two lists.
What would be ideal is being able to add the software to the master list and have it update the other two lists automagically. The unique key will of course be the software title. The field that will determine which list the row will be added to is the the [group] field. (This is where the uncertainty comes in) There will be 4 values that can go into this [group] field they are: restricted, general, engineering, media.
I would like to have the rows with "restricted" go to the restricted list, obviously, and everything else go to the general list.
I'm very new to SharePoint (~1 week) and I'm trying to simplify this process as much as possible. I'm continuing to read and watch the videos to lean more however, I understand this is a complex application. I thought I'd pose this question to people with more experience than myself to find if it's even possible. If not I'll be able to change my train of thought sooner.
Thank you for your time
This is probably a question for https://sharepoint.stackexchange.com/
But -- what I would do in your situation is only use 1 list and make multiple views.
Each view can be filtered by a different criteria (like your group column in this case) then instead of having 3 distinct lists, you can display or have a link for each view (they all get their own URI in SharePoint) seperately.
This way you only ever have to update 1 list, and you avoid the overhead/complexity of trying to copy into other lists with event recievers or workflows or something else.
If someone reading this needs instructions on views:
You can create/switch views from the 'List' or 'Library' tab when you're viewing the list. Then when you add the list to a web part page, you can select which view to use in the web part properties window.
Morning guys. I will try to be as short as possible.
We are using CRM 2011 on premises. Currently the way data flow works is that we have two systems (system X and System Y). System X have all customer information regarding purchase and System Y have all the information regarding customer's subscription choice. (news letter etc)
We bring these two database together and merge it in to one and then using thirdparty service, push it in to the CRM. (we process these data that's de-dups rows, checks for data quality etc)
PROBLEM start when the third type of data gets entered in by customer service. This guys uses Outlook to push data in to CRM (this are the only data that goes directly in to CRM)
This last method creates lots of duplicates and makes it imposible to use this data for better customer service and reporting.
Few important info: over 99% of data (in form of cases) entered in to CRM by customer service are of customers who already exist in CRM (These are the data that came from System X and System Y). The existing data have all the details (email, postal address etc..) but duplicate data that is entered by Customer service only have basic info like Firstname, Lastname and Email address.
what is the best solution to 1. merge these datas? and 2. Avoid duplicates when entered by customer services? I tried using dialog but it's asking end user (in customer service) to manually pick details they want to keep from each row. Some time these rows are more then 2-3.
I am sorry for making it so long but this issue seems to not going away. I am not looking for full on solution from you guys but any tips, link or if you have tried some thing like this before.
Many thanks for your time.
Have you looked at duplicate detection rules?
E.g. CRM Duplicate Detection Part 1: Configure Settings and Create Rules
We recently migrated from MOSS 2007 to SP 2010 platform. We have this heavily-used SharePoint Designer workflow (500 and more instances per day) that uses InfoPath to submit data. It is basically a serial Approval workflow involving many approval levels. Post-migration almost 90% of our workflow runs end in "Error Occurred" state with the following description of the error:
The workflow could not update the item, possibly because one or more columns for the item require a different type of information.
There is no set pattern for the workflows that result in an error and restarting the workflow always resolves the issue.
We have matched all columns/content type and there is no difference in MOSS 2007 and the new forms library
Permission levels of Users are not changed
A lot of sites mention introducing a pause in the workflow before the update event, but I am skeptical in doing it. What could be the possible cause/solution to it? We cannot identify anything that is common or direct us to the root cause among these 90% failing workflows. Some of the workflow instance also result in an error:
the workflow could not update the item as it was checked out to another user.
I've had the same issue in the past and the 1 minute delay resolved it. In my experience, the inconsistencies in terms of which items fail and which don't, had us looking down the path of a lock issue. It didn't make any sense otherwise. If we took one specific item in the list and tested against it, sometimes the workflow would run successfully and other times it would fail. Depending on the hardware we used, we'd get entirely different results with the same configuration.
Others with a similar issue report locking as the issue. http://social.technet.microsoft.com/Forums/en-US/sharepoint2010customization/thread/fc4e1073-d67f-449a-b443-e5805f5358c7
It appeared to me that maybe it was a locking/timing issue....it
appeared the workflow kicked off and tried updating fields in the doc
library item before the locks were released on the InfoPath form that
created the item!
When you did the migration, was new hardware involved? Also factor in that SharePoint 2010 requires more power than 2007 ever did.
The problem seems to be in fact related to attempt of changing the locked field. If you don't want to introduce 1 minute delay to your workflow before changing previously updated fields in your workflow (that should always work..) you may want to add Wait for Field Change in Current item action between updates of the same field. In some circumstances that is possible and worked quite well in may case.
There may be many cause for the issue, for me it was related to user permissions:
workflow was creating an item in another list on behalf of the user and he was having only read permissions on that list, by giving contribute permissions on another list it worked.
Before assuming a locking/timing issue, ensure that your workflow isn't updating to the incorrect column type. In our case, we were trying to update a Person or Group field with invalid data.
If it is happening randomly, probably pretty safe to rule out permissions issue. I think I was able to solve my issue, and based on my testing - so far so good.
http://www.eveningblog.com/archive/sharepoint-2010-error-the-workflow-could-not-update-the-item/
In the SharePoint publishing site I will have some banners that are Web Parts and can have any HTML content inside them. I have requirement to count clicks on that banners. Banners will have some links to external sites.
I am not sure where to store counters for individual banners. Custom List is the first thing that came to my mind but I am not sure how will it behave in concurrent access. Can I lock list (list item) and do the counter increment ? What will happen for other list access if it is in lock state ? Will it fail or just wait ?
Are there any alternatives to storing counters somewhere else ?
There are lots of places, here are the two most popular:
Property Bag (most likely on the Web) which is a number you increment
Inside a list
Of these, I have successfully done it with a list on our blogging solution, you can see it here: http://community.zevenseas.com/blogs, where I'm tracking views for each post. I took this approach because I like to see more than a number, eg. referrer, ip, etc.
Things to keep in mind:
You need to keep a close eye on the number of items you are storing. SharePoint doesn't like lots of items in a list. To manage them put them in folders, a folder for each banner, and then subfolders for each month.
I would keep a list with each of the banners (just their name or more) in it, then create a second list to store the views. In the list where you store the views have a lookup back to the list storing the banners. On the original banner list you can then create a new column which "Counts" the number of Views related to each banner item.
Again, be very careful about the number of items you are expecting, but this works pretty nicely for us.
Don't forget a small database will allow you to store page hits against whatever you want. You can then call a stored proc and that database "just takes care of it". You don't have to worry about access and concurrency (because you used a transaction riiiight!).
A SharePoint list is easy because they are there out of the box, but consider that they have a lot of overhead for adding values and even reading from. They are also editable by a site administrator, which may be find, depending on the number of administrators you have. A list is easier to provision than a new database, so in the end you do need to consider the two options carefully.
Just because SharePoint has a hammer does not mean everything is a nail :)