SharePoint Help

Installing SharePoint 2013 on Server 2012

Robert Schley — Thu, 30 Jan 2014 20:58:42 +0000

So this week I’ve been working on installing SharePoint 2013 on Server 2012 server environment for our new Fast Track Power User SharePoint Training. This server would give back the ability for students to have their own complete server to work on. There have been some performance issues that have prevented this and this week has been working on overcoming them. I wanted to take some time to write down some notes and tips for this process that might be able to help spare some pain for others. Per this Microsoft article, SharePoint 2013 is not currently supported on Server 2012 R2. I found this out after going through high-water to get everything prepped and then stumbled across this little fact that the prerequisite installer will not complete. Install EVERY update to your Server 2012 prior to installing SharePoint 2013. This will save you many, many headaches on trying to troubleshoot configuration errors after installation. The worst of which I received was an undetermined inability for Search Service to see my SharePoint server. I’m not sure how I forgot this step, but apparently my server had updates turned off and did not apply any before SharePoint was installed. OFFICE WEB APPS doesn’t play well with anything else! You HAVE to put it on its own server. It will literally remove other sites in IIS and replace them with its own content. Plan for this! It requires minimal resources though and is using 1 processor and 2 GB of ram in our environment. According to Microsoft documentation, 8 GB of RAM should be good enough for up to 10k users. Setup Office Web Apps (WAC) using https. This may require you to setup a Certifying Authority somewhere but it considerably simplifies the WAC setup between it and your SharePoint server. Trust me. I hope that this can save some pain for some people. Best Wishes on you future SharePoint success!

The post Installing SharePoint 2013 on Server 2012 appeared first on SharePoint Help.

SharePoint Connect to Outlook: Work with List and Library Items in Outlook

TL Ferrell — Tue, 26 Nov 2013 21:15:42 +0000

The SharePoint Connect to Outlook feature is a stellar example of the tight integration between SharePoint and other Microsoft products. While SharePoint 2013 offers even more integration than before, Connect to Outlook has been part of SharePoint since the beginning. What benefits does this easy-to-use feature offer? By connecting Calendars and other SharePoint features to Outlook, you can browse and even edit and create items from within Outlook. This allows you to work with these items without opening the SharePoint site. Work with Calendars, Contacts, and Tasks with SharePoint Connect to Outlook Outside of email, the three most commonly-used areas of Outlook are Calendars, Contacts, and Tasks. These features have corresponding Lists in SharePoint. Therefore, it seems like a no-brainer that each of these Lists in SharePoint can be connected to their corresponding area of Outlook. If the user has Read permission on the List in SharePoint, then they will be able to browse and open the items in Outlook just as they do in SharePoint. If they have Contributor permissions in SharePoint, they will also be able to edit, or even create or delete, the items in Outlook. Whatever permissions they have in SharePoint, they will have the corresponding permission when working with that List in Outlook. To create the connection: Go to the desired List on a SharePoint site (for example, a Calendar). In the List ribbon, click the Connect to Outlook button. Depending on your browser settings, you may get a dialog box from the browser asking if you want to allow this type of connection. Click the Allow button. To view the Calendar in Outlook: Navigate to Outlook (or open Outlook if it is not already open). You may get a dialog box from Outlook asking if you want to allow the connection. Click Click Yes. The SharePoint Calendar will be added to the Other Calendar group in the left navigation bar of the Outlook Calendar. You can view the Calendar by checking the box beside its name; uncheck the box to hide it. BONUS TIP: See the SharePoint Calendar combined with your personal calendar, or other calendars, by using Overlay Mode. This does not add the SharePoint events to your calendar, but allows you to see all events in a single calendar grid. Follow the same steps to connect SharePoint Contacts Lists to your Outlook Contacts, or SharePoint Tasks to Outlook Tasks. (NOTE: In SharePoint Server 2013 with MySites enabled, the feature is called Sync to Outlook, and this is a true synchronization feature. Your MySite will contain a master list of all of your tasks across sites and including tasks in Outlook.) SharePoint Connect to Outlook also works with Discussion Boards, Libraries, and More Many users know about using SharePoint Connect to Outlook to view and work with items in Calendars, Contacts, and Tasks. What is often overlooked, however, is the ability to use this feature for other Lists and even Libraries. The Folder view in Outlook is where you go to see all of the SharePoint Lists (and Libraries) you are connected to. You see not only the Calendars, Task Lists, and Contacts Lists, but any other SharePoint List or Library. The title of each connection will start with the name of the site or subsite where the List is located, followed by the name of the particular List or Library. Again, whatever permissions you have on that List in SharePoint will carry over to Outlook. For more information about working with SharePoint Calendars, see my previous blog posts Color-Code Events on a SharePoint Calendar and SharePoint Calendar Overlay with a Library or Other List. Stay tuned for additional posts on SharePoint Calendars. PremierPoint Solutions offers a number of SharePoint training courses, at both the Beginning and Intermediate level. In addition, we have an economical SharePoint CBT option for those who would prefer a self-paced video class.

The post SharePoint Connect to Outlook: Work with List and Library Items in Outlook appeared first on SharePoint Help.

What Is a SharePoint Site Collection Administrator?

TL Ferrell — Wed, 20 Nov 2013 00:08:44 +0000

When you think about user permissions in SharePoint, you typically think of the four main out-of-the-box permissions levels: Full Control, Design, Contributor, and Read. These, and other permissions levels, exist at every level of a SharePoint site collection. They are established on the top-level site, and are available for all subsites, list, libraries, and items. There is another type of permission that overrides even Full Control: The SharePoint Site Collection Administrator. How is the SharePoint Site Collection Administrator Different from Full Control? First, what can an Owner do? When a site collection is first created, SharePoint automatically creates three user groups. The name of the groups includes the name of the site by default. If I create a site collection called Acme Supplies Intranet, the three groups will be Acme Supplies Intranet Owners, Acme Supplies Intranet Members, and Acme Supplies Intranet Visitors. The Owners group is assigned Full Control permissions, the Members have Contribute, and the Visitors have Read. Of course the names and permissions can be changed, and additional groups and permission levels can be created as needed. These are the starter set, however. At Acme, the user WECoyote is in the Owners group. Because he has Full Control permission, he has complete control over the site. Not only can he create and configure lists and libraries, he can create subsites. He can also perform some higher administrative functions for the site collection such as setting permissions of other users, view site analytics logs, and the like. TIP: For a spreadsheet with the out-of-the-box groups and permission levels in SharePoint 2010, see Sharepoint Server 2010 Groups and Permissions Reference Chart. OK, so how is the SharePoint Site Collection Administrator different? The SharePoint Site Collection Administrator has an additional set of tools to manage the site. The SharePoint Site Collection Administrator can be thought of as a Super Owner. They have ultimate control over everything in the site collection that can be managed in the web interface. Site Collection Admins can manage the functionality of features such as Search, the Recycle Bin, Document ID, and more. They can view the Audit Log Reports, work with site collection policies, manage the site collection caching, and activate or deactivate Site Collection features. The Site Collection Admin can also add other Site Collection Admins. In short, the SharePoint Site Collection Administrator can do anything in the site collection that a system administrator can do. It’s important to understand that the Site Collection Admin is not a full system administrator role. This role does not manage the SharePoint farm or server software, and is not a network or server administrator. In the Acme Supplies Intranet, RRunner is the Site Collection Admin. Mr. Runner cannot work in other site collections or Central Administration unless those permissions have been granted separately. Is that the only distinction for the SharePoint Site Collection Administrator? Beyond the features in Site Collection Settings that the Site Collection Admin can manage, there is one other permissions issue to be aware of. The SharePoint Site Collection Administrator cannot be locked out of any subsite, list, library, item, or page on the site. The permissions inheritance for any of these elements can be broken at any time, and permissions changed so that even users with Full Control rights have lesser permissions or even no permissions at all. In all cases the SharePoint Site Collection Administrator will always have full access to all of the elements and all of the data. This is especially handy when a site Owner accidentally deletes their own user account or group when creating custom permissions! Who should be a SharePoint Site Collection Administrator? The answer to this question will depend a great deal on your organization’s SharePoint structure and culture. In some organizations there may be only one site collection, and the SharePoint Site Collection Administrator is someone who is also a system administrator or other IT staff. If, however, there are multiple site collections, a more beneficial use of resources would be to assign a trained power user to be the SharePoint Site Collection Administrator. If the Acme Supplies SharePoint system grows to include, for example, a Records Center site collection, then the company Records Manager BBunny could be made the Site Collection Administrator. The overall system administrator CJones still retains control over the overarching platform, but does not have to be involved in the day-to-day running of the site collections. In recent blog post (5 Signs You Have a Bad SharePoint Implementation) I described the downside of having power users that have no power. SharePoint was meant to be a collaborative system where out-of-the-box features could be managed by non-technical staff. It’s true there’s a learning curve associated with using, developing, and managing SharePoint, but by properly selecting and training the right process owner or support staff, you can allow areas of your organization to take control of their own collaborative needs. This allows truly specialized staff in IT to do what they do best, while allowing end-user tools to be managed by end-users. Turning over the role of SharePoint Site Collection Administrator to information workers is a step in that direction. Do you or your users need to learn more about SharePoint? PremierPoint Solutions offers both SharePoint 2010 training and SharePoint 2013 training, from intensive introductory courses to intermediate and advanced courses in SharePoint document management, InfoPath, SharePoint Designer Workflow, and SharePoint self-serve business intelligence. If you need more help in getting started, we also offer SharePoint consulting services.

The post What Is a SharePoint Site Collection Administrator? appeared first on SharePoint Help.

Add SharePoint metadata to Word documents

Robert Schley — Tue, 12 Nov 2013 16:23:30 +0000

“Why would you want to use SharePoint for storing documents? We’ve always used file shares and it works just fine.” Why indeed? The simplest answer is that there is so much more that SharePoint CAN do. It just requires a little push in the right direction and a little knowledge on what CAN be done. One of the wonderful tools that comes from using SharePoint as more than a file store is being able to add SharePoint metadata to Word documents. Unfortunately, this ability to link information within a document to metadata outside the document (but still inside SharePoint) is not intuitive or automatic. There are a few steps involved in getting it setup with a small change in how individuals operate to get this to work smoothly. The first step is to have a SharePoint library that you want to use with the appropriate columns that you want linked to your document. This is important because it allows us to add the metadata columns as Word quick parts. For this demonstration, I’ll be using my Office 365 account. Office 365 is almost the same as SharePoint 2013 so my SharePoint 2013 Training directly applies to it. I have my library “Test Reports” with a few extra columns that I’m going to add to my Word document. Now I have to add these columns as quick parts to my document. This requires Word to be aware of the columns. I will choose to create a new document in the library that I will name “Report Template”. Once it is created, I’ll open this document with my local copy of Microsoft Office Word. Under the ‘INSERT’ ribbon, I can then select the columns from the library as quick parts. I’ll create a dummy report and insert my columns of information. At this point, I save the document to be used as a template and would probably lock it as a read only copy that users can download to fill out. I downloaded a copy of the template and filled in some information. The fields that require a date give a dropdown for selecting a date from a calendar. The column that I added that was of type ‘choice’ has a dropdown with only the choices available. I then do a “save as” and save it to my Office 365 library. The columns that I added to the document automatically populate the columns in this library and can now be used within SharePoint for creating custom views and reports. The one downside to this is that you can’t edit the fields in Office Web Apps. You can choose to edit the properties of each record in the library and the information will be automatically changed inside the document. As a real world example, I knew a gentleman that used this same method to create report templates like you see here. Once the reports were created, the field agents just had to drop them into the correct library (which can be mapped like a shared drive if your users are still adjusting to SharePoint). Since all the information in the report was pulled as metadata into SharePoint, the information could be used for multiple dashboards that were updated in almost real time. This created a streamlined process from the agent to the SharePoint Business Intelligence dashboard that the executives used to make decisions. After all, that’s what we’re always looking for, streamlined processes for greater efficiency.

The post Add SharePoint metadata to Word documents appeared first on SharePoint Help.

The Power of [Me] in SharePoint Library Views and List Views

TL Ferrell — Fri, 25 Oct 2013 15:59:33 +0000

Have you ever wished that you could look at a large SharePoint list or SharePoint library and easily find only those items that were relevant to you? Perhaps you’d like to see all the Tasks where you are in the Assigned To field, or all of the documents you created in a Library. It’s easy enough to filter for those items on the fly by using the drop-down menu on the Column headings, but wouldn’t it be nice to see only those relevant items when you first navigate to that page? This post will show you how to create a SharePoint Library View (or List View) that filters for the current user who is logged in to the site. Add a special filter to any Standard SharePoint Library View It may seem obvious that this could be accomplished by applying a Filter to the View Settings, and it’s easy to see that you could create a filter for a particular user. However, there is a special filter criteria that can be applied that will match up the relevant Column (Created By, Assigned To, or any other Person or Group field) with the current logged in user. This filter can be applied to either Public Views (created by someone who has Design or Full Control permissions on the site or list/library) or to Private Views (which can be created by anyone with at least Contributor permissions). Before we get started, it’s important to note that this technique only works when users are logged in to SharePoint with their specific SharePoint user account. In cases where users are logged in with a generic account, but the Column data will reflect an individual user, this technique isn’t helpful unless the user switches to their personal login.* You may not realize it, but the built-in Tasks list template has such a view already in place. Choosing this view would match the current user with the ID in the Assigned To column, and show only those tasks where the current user has been assigned: In this example, we have a library that contains document sets for bid proposals. Our goal is to create a new SharePoint Library View which shows only the documents where the logged in user is the Sales Person. We also want this to be the default view for that library, so that everyone who navigates to that Library’s page will see that view first; they can switch to a different view if needed at any time. First, use your favorite method to start a new view. One handy method is to use the View menu drop-down and select Create View. We want this new view to be a variation on the existing All Documents view, so click the link to copy it. Add a View Name, and check the box to Make this the default view. Scroll down to the Filter section. Choose Show items only when the following is true. Select the Sales Person column as the basis for the filter, then make sure the second field is set for is equal to. In the third column, rather than entering an individiual’s name, type [Me] as the criteria. Be sure to include the brackets! This special value is what will compare the Sales Person field to the ID that is logged in to the site. Click OK at the bottom or the top of the page. Now when Cynthia or Jared visits the Library, by default each will see only those proposals they are responsible for. Want to know more about creating SharePoint Library Views and List VIews that help users get the information and documents they need quickly? Take a look at our SharePoint training courses such as Introduction to SharePoint – Using SharePoint Server 2010, Using SharePoint 2013 or Office 365 SharePoint, or for more experienced users, Designing Document Management and Records Management Systems in SharePoint. * You may ask under what circumstances that would happen. In my previous organization, there were a number of dumb workstations throughout the organization, where users logged in not via Windows but through an alternate system. They could navigate to the SharePoint site, but the workstation passed only a generic Windows ID to SharePoint. That generic Windows ID had Read permissions on the sites, so users could browse, but if they needed to operate on the site with their personal Windows ID, they had to Log In as a Different User to pick up their individual permissions. In this case, in order for a [Me] filter to be useful, the user would have to switch logins from the generic to the individual first.

The post The Power of [Me] in SharePoint Library Views and List Views appeared first on SharePoint Help.

When should I create a new SharePoint Site Collection?

Robert Schley — Wed, 23 Oct 2013 18:31:26 +0000

I had a question in one of my SharePoint classes the other day from a very sharp student. “What is the best practice for deciding when to create a new SharePoint Site Collection?” Well for starters, I’d like to say that any time you start talking about “best practices” there always has to be a disclaimer of, “It depends.” Rather than try to hammer out a hard and fast rule, I can give some general thoughts on whether a new site collection makes sense for your specific circumstances. Inheritance - this is the biggest reason. Security (specifically groups) and Content Types are inherited throughout the structure of SharePoint, so one huge reason for creating a new Site Collection is that you want the content or security to be very much separated from what you currently have. You will lose some of the functionality with having to recreate some structure, but it may be that there is absolutely nothing in common with the rest of your information and it will not affect you. Site Collection features - there may be times when you have certain site collection features turned on that make life a little too complicated. The publishing feature is one example. While I love the publishing features and you can generally do some awesome stuff with them, there are times when it makes doing things a tad bit more complicated. The only real way to separate this out is to have separate site collections. Site Collection Administrators; this one goes along in a similar vein with the inheritance but I consider it to be distinctly different enough that it’s worth mentioning. The Site Collection Administrator, for the most part, knows no boundaries within a site collection. There is an implied authority that goes beyond being assigned permissions. In some cases you might want to assign this authority to different people depending on what is contained within the site collection. Perhaps you have different divisions that should have different people assigned as the responsible parties, hence the different site collection administrators. I think that covers the major things to consider in creating a new site collection. Individual experience may vary, but these general guidelines will get you started. If you have further criteria that you think is important, let me know in the comments.

The post When should I create a new SharePoint Site Collection? appeared first on SharePoint Help.

Allow the User to Reset (Deselect) InfoPath Option Buttons

TL Ferrell — Thu, 10 Oct 2013 13:58:44 +0000

Like many form applications, InfoPath has a Option Button control. InfoPath Option Buttons (sometimes called Radio Buttons) are useful when you have a very short list of choices (usually just 2 or 3) and want to expose all the choices on the form, rather than having the user click a drop-down control. Option Buttons allow selection of just one item in the group – they are all bound to a single field, and only one selection can be made. Working with InfoPath Option Buttons In our class InfoPath 2010 and SharePoint Server 2010 No-Code Workflow Deep Dive, students get some hands-on practice working with InfoPath Option Buttons. They can be a little tricky when you are first learning to develop forms, as they don’t behave exactly like other form controls. There can be a usability issue, too; once the user selects one of the choices (or there is a default choice already selected), they can’t UNselect it. They can change to another selection, but they are stuck having one of the choices selected, even if they really want to leave the group blank. Luckily the form developer can add a little functionality to the form to allow for any selection in that group to be cleared. In the example below, there are Option Buttons for registrants to indicate dietary restrictions. There is no default content, and the field is not required. So, it’s possible for the form to be submitted with no option selected. If a user makes a selection and then changes their mind, or simply clicks on an option by mistake, however, having a way to clear the selection will ensure that the form is submitted with accurate data. In the example below, Claire accidentally selected Kosher. As the form exists now, her only options would be to select another restriction, or to close the form and start over. To allow her to clear the selection, we’ll add a button with a rule to reset the Dietary field to empty. The first step is to add the Button Control to the desired spot in the form. Next, update the Control Properties to change the button label from the generic “Button” to “Clear Selection.” In this example, I also made the text 9 point instead of the default 10 point, and made the button smaller than the default size. You could also have a very small unlabeled button, with a text label to the side. You could also use a hyperlink control. The next step is to add a Rule to the button to perform the desired action. Click the button to select it, then use the Add Rule button in the Ribbon to choose When This Button Is Clicked, then Set a Field’s Value as the Action. The Rule Details dialog box will then appear. Click the Field Selector button. In the Select a Field or Group dialog box, choose the name of the field you wish to clear. With most Rules of this type, you would then go on to use the fx button next to the Value field to indicate the data that should be added to the field. In this case, however, we are trying to clear the field completely. So, leave the Value field blank. Now the form has a button that will deselect any selected Option Button for the Dietary field, and there will be no value associated with this field when the form is submitted. PremierPoint Solutions offers SharePoint 2010 training and SharePoint 2013 training in-person and live online. We also offer introductory self-paced SharePoint CBT course for those who are not able to attend a live class.

The post Allow the User to Reset (Deselect) InfoPath Option Buttons appeared first on SharePoint Help.

InfoPath vs ASPX: Which Electronic Form Is the Most Useful in SharePoint?

TL Ferrell — Mon, 26 Aug 2013 14:25:35 +0000

Last week I presented one of our most popular webinars: Build Better Forms with InfoPath and SharePoint. As part of the registration process, one of the attendees asked about the limitations of InfoPath when compared to ASPX (Active Server Page Extended File) forms. This isn’t a topic I’d addressed in previous webinars, but I added a few slides to discuss it. In this post, I’ll expand on that information and discuss the pros and cons of InfoPath vs ASPX. InfoPath vs. ASPX: Background InfoPath forms can be deployed in a variety of ways, but in this post I’ll concentrate on how they work when published to a SharePoint 2010 or SharePoint 2013 site. InfoPath is a Microsoft Office WYSIWYG application used to create – and sometimes complete and submit – XML (Extensible Markup Language) forms which use DHTML (Dynamic HTML) and XSLT (Extensible Style Sheet Language) for formatting and interactivity. A form template is created, with an internal data source and form controls that are bound to the data. The template is published to a special Form Library on the SharePoint site. When the form template is published, any or all of the fields in the data source may be promoted to be visible metadata columns in the library. Each time a form is completed and submitted, a new InfoPath document is created which contains the data provided, and any of the promoted fields are metadata for that document. The form can also submit data to other data sources as well, such as directly to SQL or Access or to other systems via a web service. InfoPath can have “code behind” if the functionality of the form needs to be extended via a language such as JavaScript or C#. ASPX forms are created in Visual Studio (or, in some cases, SharePoint Designer). They are deployed as simple web pages in a SharePoint site; the entire purpose of the form is to gather data and send it somewhere. This is usually done through a method built into the form, and programming on the server processes the information and sends it on. Of course, developing these forms requires someone with programming know-how, whereas an InfoPath form can be built and deployed by a power user. There is a common assumption that ASPX forms are, by default, more sophisticated and powerful. That CAN be true, but depending on what functionality is needed, a careful comparison of InfoPath vs ASPX can reveal that an InfoPath form actually can be the better solution. To explain the differences, first it’s helpful to understand a little bit more about the integration between InfoPath and SharePoint. InfoPath and SharePoint As mentioned above, the end user can complete and submit a form using the InfoPath client application. They go to the SharePoint library where the template has been published, and click on Add Document or New Document to open a blank copy of the form. The form opens in InfoPath (operating in Filler mode); the user fills in the fields and submits (or saves, depending on how the form has been set up). This, of course, requires that the end user have the InfoPath client application installed on their computer. For organizations which have SharePoint Enterprise with Forms Services activated, the form designer can choose to have the form open in the web browser rather than in InfoPath filler. This means that the end user needs only a browser to open, complete, and submit the form. The downside to this option is that there is slightly less functionality available in browser forms than what is available with a filler form. In SharePoint 2010 a new option became available: InfoPath can be used to edit the out-of-the-box list item forms. In previous versions of SharePoint, you had to use SharePoint Designer if you wanted to customize the New, Display, and Edit forms associated with a list. In addition, deployment and functionality of these custom forms often didn’t work well. With SharePoint 2010 with Forms Services, customization of forms is done with InfoPath, and you only have to edit the master rather than separate forms for New, Display, and Edit. The functionality available for list forms is a subset of what’s available for from-scratch browser forms published to a Form Library. InfoPath vs ASPX: The Comparison So, if you compare InfoPath vs ASPX, what is the result? You might think that ASPX forms would give you all the functionality of an InfoPath form, and then some. That’s true … and it’s not. The fact is that InfoPath can do some things that ASPX can’t. So, there’s an area of overlap, but each technology has unique benefits. Here is a summary of those unique benefits that each provides: InfoPath ASPX Can receive from / send to multiple data sources Can make use of Managed Metadata Repeating / nested data JavaScript / JQuery and Server side code support Multiple views of data CSS Support “No Code” solutions Cascading drop-downs without JavaScript Automation via InfoPath Rules Quick development / deployment Suitable for development by power users In summary, InfoPath is a valid, professional-level tool that can be used by power-users and developers alike to create powerful XML forms, whether or not they are published to SharePoint. It falls short when complex, sophisticated coding is needed, but has features that make it more flexible in some ways than ASPX forms. An added benefit is that development and deployment time can be much shorter, and development does not require a .Net programmer. A comparison of InfoPath vs ASPX is not a slam-dunk: The best solution for any given situation could be the “end user” tool InfoPath. Many of these InfoPath features are demonstrated in my webinar, a video of which is available on our web site: http://sharepointsolutions.com/SharePoint-Training/Pages/Webinars.aspx. We also provide hands-on instruction and practice with these features in our course InfoPath 2010/SharePoint Server 2010 No-Code Workflow Deep Dive. For information on our other classes, visit our full list of SharePoint training courses.

The post InfoPath vs ASPX: Which Electronic Form Is the Most Useful in SharePoint? appeared first on SharePoint Help.

Add a SharePoint Designer Workflow Email BCC Recipient

TL Ferrell — Thu, 23 May 2013 16:32:04 +0000

One of the most common Actions used in SharePoint Designer custom workflows is “Send an Email.” This Action allows you to specify recipients, subject lines, and the email body with combinations of text and dynamic content. One desired feature that seems to have been left out, however, is the ability to send a blind carbon copy (BCC) to a recipient. There seems to be no BCC option in the email creation dialog box. If you have that need and didn’t know better, you might add a second Send an Email action to send a separate notification to that recipient. Luckily, there IS an easier way to add a SharePoint Designer Workflow email BCC recipient – it’s just not obvious. Add the SharePoint Designer Workflow Email BCC Recipient The email design dialog box in SharePoint Designer (SPD) 2010 and 2013 is a great improvement over the one in SPD 2007. Among other things, the text in the email body can now be formatted with font choices. Hyperlinks are easier to construct, and building dynamic subject lines that combine text and data is easier as well. The first step is to create the email as you normally would, filling in the To: field and the CC: field (if needed) as usual. Once the email has been built and you’ve clicked OK, you’ll be returned to the Edit Workflow window. To add the BCC recipient, select the line that contains the Send an Email Action by clicking on it (just be careful not to click on the link that would open the email dialog box again). Next, click on the Advanced Properties button in the Ribbon. A dialog box will open that has a table containing the parameters of the email – the To, CC, Subject, and Body. At the top of this dialog box is the field for the BCC. Just click the String Builder button to open the Select Users dialog box. This will allow you to select the recipients for the BCC just as you do for the To and CC fields. So, it’s not a lot of work to add a SharePoint Designer Workflow email BCC recipient; the secret is knowing to go to the Advanced Properties dialog box to do it. Many of our SharePoint training classes include lessons on creating SharePoint Designer Workflows. For particularly in-depth coverage, take a look at the course InfoPath and SharePoint 2010 No-Code Workflow Deep Dive.

The post Add a SharePoint Designer Workflow Email BCC Recipient appeared first on SharePoint Help.

Custom Discussion Board Rollup using Content Query Web Part and XSL

Robert Schley — Thu, 04 Apr 2013 20:12:42 +0000

A problem was recently posted on one of our SharePoint Solutions Help Community Forums. The situation was that an individual wanted to “roll up” multiple discussion boards from multiple sub-sites; essentially pulling the content from different discussion board lists. One solution is to upgrade to SharePoint 2013 and take advantage of all the new social features such as Communities. Another option is to buy a third-party web part such as this one. Neither of these may be possible in your organization. In this post, I will present a solution that involves modifying the styles available for presentation within the Content Query Web Part. The content query web part can roll-up information from multiple sites, based on Content Type. Unfortunately, discussion boards in 2010 are not like most lists. Only the first post in each thread has a “Title.” That first post is the Discussion Content Type, which is actually a folder with metadata. All the replies are Message Content Types within that folder. This means that if you don’t limit the content query to only folder-type content types then you receive many, many items that display “(blank)” for a placeholder for the missing Title field. Another problem is that each of the links will take you to a page with just that single message instead of showing the entire thread. In this age of Facebook and ongoing social dialogue, this setup doesn’t work for most people. Begin by editing a page, inserting a web part, selecting “content rollup”, and choosing content query. Edit the web part and set it to query all Discussion Board “Folder Content Types” group from the parent site of the Discussion Boards you want to roll up. In the example below, my discussion boards were in separate subsites of the Production site. Initially, the Content Query web part looks like this. Clicking on any of these links take the user to a single page displaying only that message: Clicking through obviously doesn’t show the whole thread and clicking “close” takes the user back to the page with the query. This is not what most users are expecting. This is an example of a style. A style is simply a markup template that is applied to the information you give it. The good news is that styles can be added to or modified. Each style is pulled from a specific file on your SharePoint installation, ItemStyles.xsl. So one way to make this look better and act better is to modify those styles. A familiarity with the basics of computer languages and/or markup languages comes in very handy, as I found out. The location of these styles is found in a folder on your top level site in a site collection. If you open up your site with SharePoint Designer and choose the topic of “All Files” in the left-side menu then you will be able to browse to the folder “Style Library” –> “XSL Style Sheets”. In this folder there is a file called “ItemStyle.xsl.” You can edit this item from within Designer. I added the following into this file right before the last /xsl:template tag. Because this is a markup language it gets swallowed up by web browsers in its correct syntax so I couldn’t copy and paste the text in this blog. Here’s an image of the correct lines. This inserts a new style into the ItemStyle.xsl using the XSL standards. I save the document and return to SharePoint. Now I can choose the style I just created when editing the web part. So now when I select the “CustomRollup” style I get this: Not too impressive until we click on one and receive this: Now we get links that take us to the full discussion with the default view for that discussion, whether flat or threaded. Rather than a “close” button, the browser’s back button will return us to the appropriate page. You can add to the code in order to make it look better. I got a lot of help from W3schools where I learned that XSL was simpler than I thought and from Stackoverflow.com for specific help on getting a hyperlink displayed properly. This instruction set makes much better and more advanced use of XSL to provide an experience in styles. There are limitations and problems with this solution (just like any other) in that if Microsoft ever chooses to update the file, your custom changes will probably be overwritten without notice. I will continue to play with this and see if I can make it better looking, but I hope this helps you get started on aggregating your discussion boards for a better user experience in SharePoint 2010.

The post Custom Discussion Board Rollup using Content Query Web Part and XSL appeared first on SharePoint Help.