2012년 6월 12일 화요일 오후 1:25
I am new to SharePoint and see so many different types of sites and libraries that I am confused as to what we should be using. We have the following needs:
- On-call person receives notification of a failed job and should be able to search for this job by name on SharePoint in order to read up on it, what it's supposed to do, troubleshooting steps, contact person, etc. This document should allow attachments.
- People responsible with a certain group of reports should also have a repository where they can see all of these reports, read their specifications, open different files attached (like file layouts), etc. Each of these reports should also have a calendar
attached that you can configure to notify certain people when some event related to the report happens. I guess this is very similar to the one above with the addition of the calendar.
- Ideally, we'd like to be able to apply tags/keywords to all of the above for easier searches. I've seen full-text search takes a very long time.
Thank you in advance.
2012년 6월 12일 화요일 오후 1:33
Examine the Form Libraries.
You will need InfoPath 2010 (to design the form) and quite possibly Visio 2010 (for the intricate workflow). If you want to have a really customized presentation of the data, then SharePoint Designer 2010.
hope this helps.
- 답변으로 표시됨 rayneverlearns 2012년 6월 12일 화요일 오후 2:52
2012년 6월 12일 화요일 오후 1:48Hmmm... Why do you recommend a form? I just don't know what to create, whether a library, a list, a page or a site and what kind of each of these. So many options! LOL A wiki, maybe?
2012년 6월 12일 화요일 오후 2:05
1. Support library - There are a variety of ways you could do this, each with pros/cons. A Wiki would work. It allows attachments (links to docs). It also is very free-form. If you'd rather that each writeup of troubleshooting steps, etc., have the exact same structure, then a wiki wouldn't be best. A wiki would be good at allowing multiple users to modify the procedure, as well as allowing users to easily see who made what changes to the doc. As with everything in sharepoint, you could require the individual wiki pages to be approved if necessary.(A wiki is not the only way. If you work for a company where the look of the site is critical, then you could use a publishing site. Same basic idea, users, based on permissions, could edit the pages, but publishing would allow you to set up page templates to rigidly enforce a particular look and feel.)
2. Report system? Could you provide more details on this? What do you mean by "open different files attached" to a report library. (When I hear the word "report", I think of SQL Reporting Services reports. Is that what you mean?)
3. tags / keywords. Spend some time reading up on content types, custom search scopes, and using custom fields in search. Full text search in sharepoint does not take a long time, but you do want things to be structured well, so that a user can easily search for a support document and not get results from other sites / libraries that just gum up the results.
- 답변으로 표시됨 rayneverlearns 2012년 6월 12일 화요일 오후 2:52
2012년 6월 12일 화요일 오후 2:14
Thanks for your detailed response.
Here's more details on point 2. We constantly need to report to a government agency and there are many reports in many different formats that we send them at different times. All we need is a place were we can go see which is the next report due, see documentation, specs, layout (all of which have been provided by the agency), business people involved, etc. This would be our go-to place for anything related to these submissions. We also want this calendar to notify different people for different reports when reports are due, feedback is required, etc. We would set up these events manually. For example: Report ABC is due the second Thursday of every month, but 3 days prior, departments X, Y and Z must be notified so that they go and check the data before the report is generated. The site would serve as a reference and scheduling tool. I hope that clarified.
Thank you again.
2012년 6월 12일 화요일 오후 2:46
Ah, so you're not storing reports, just the metadata about the reports. Why not just a custom list? You could create custom fields for everything you mentioned. And, lists support attachments (multiple attachments per list item!) If your list has a date field, then create a calendar view for the list. Also, create a few other views based on that date (the next 10 upcoming reports, etc.) You could even use audiences with CQWPs to show users just the reports that apply to them.
The alerts will be trickier. You could create a calculated field for the "three days before" alert, but it sounds like each report will have its own rules re notifications. If so, that will be problematic. Also, while it is (relatively) trivial to set up a sharepoint designer workflow that sends notifications based on a date, getting them to automatically repeat on a schedule is not trivial.
A couple options:
1. create a second list that stores the "report instances". So, list A will store the metadata for each report. List B will have one record for each date that it needs to be run (perhaps it will only need two columns: a lookup to List A, and a date field). Create a sharepoint designer workflow based on list B that sends out appropriate notifications.(Yes, someone would have to populate that list...)
2. a timer job (code) or a scheduled powershell script (code) that queries the list and sends out notifications as needed each day. (
Note: I would think this could be done via a calendar list, a sharepoint designer workflow, and recurring events in the calendar. This did not work in 07, and, to my knowledge, it still doesn't work in 2010. Though, I haven't personally tried it in 2010.
- 답변으로 표시됨 rayneverlearns 2012년 6월 12일 화요일 오후 2:51
2012년 6월 12일 화요일 오후 2:51Wow, that's a lot to process, since I am not familiar with ANY of that. I will give those options a try and see if they fit the bill. Thanks a lot!