Sharepoint Alerts and Email Integration in General

In the Basic Sharepoint List Features post, I mentioned alerts, and how you can setup email-based alerts on any sharepoint list. This post looks a little deeper at this functionality, and explains how you might go about setting up an alert yourself.

Yep, you read that right, any end-user can setup the alert themselves without any administrator involvement.

Now, I’ll confess I’ve got an ulterior motive here. When we first setup these Engineering blogs, we setup an alert to a mailing list. And apparently, now folks want to get on that mailing list in order to get alerts from these blogs. And as you’ll soon see, that’s not really required–anyone can setup their own alerts without needing to be on a mailing list.

We’ll also be looking at Sharepoint email integration on a wider scale than just alerts. Contrary to what you might have been told previously (and the marketing material is definitely misleading), there is really no reliance on Exchange for Sharepoint email integration. However, there are Exchange-Sharepoints integration points. We’ll get to this larger integration story after looking at alerts first.

So setting up alerts can seem a bit tricky because the interface to do so varies based on the site/page/list you are currently at. For Document Libraries, you’ll find an Actions menu with an Alert Me option. But for most other Sharepoint locations, you won’t find an action menu. Regardless of where you are, you should find the authentication (or profile) menu in the upper right corner. It’ll say something like “Welcome NETID\barkills” or “Welcome Brian Arkills” or some variant. If you haven’t authenticated, it’ll say “Sign In”, and you’ll need to login first before you get a drop-down menu. If you click on it, what menu options you see depends on your level of permissions for the site. If the site has permitted anonymous access, and you do not have at least read permission on the site, then you’ll only see two options:

  • Sign in as a Different User
  • Sign Out

If, however, you have at least read permission on the site, then you’ll see more menu options:

  • My Settings
  • Sign in as a Different User
  • Sign Out

And if you happen to be a site owner, you’ll see even more menu options:

  • My Settings
  • Sign in as a Different User
  • Sign Out
  • Personalize this Page

The menu option you need in order to setup alerts is the ‘My Settings’ one. So in some cases, you may need to request read permissions.

Within the My Settings page, you’ll see a portion of what is known as your Sharepoint profile. Assuming you are using your NETID user account, you should see an email address listed which is your official forwarding email address. There should be a bar with a link entitled ‘My Alerts’ on this page. That will take you to the ‘My Alerts on this Site’ page. From there, you can choose the ‘Add Alert’ button/link. This will take you to a page where you can choose which sharepoint list you want to track. For this blog, you’d probably want to track the Posts list. After making a selection, and clicking Next, you’ll see a page where you can configure the details of your alert.

You can change when alerts are sent, with options of:

  • all changes
  • new items are added
  • existing items are modified
  • items are deleted

And you can additionally filter on these conditions:

  • anything changes
  • someone else changes an item
  • someone else changes an item created by me
  • someone else changes an item last modified by me
  • somone changes an item that appears in the following view

And finally, you can choose the frequency of email alerts, with the following options:

  • send email immediately
  • send a daily summary (specify time)
  • send a weekly summary (specify day & time)

Now, let’s move from the end-user perspective to the Administrator perspective.

To enable alerts on a sharepoint site, you first need to go into the ‘Central admin’ site for the sharepoint farm. From the Application Management page, you need to configure the Web Application Outgoing Email Settings. Each web application can have a different set of settings, where what is required/configurable is:

  • Outbound SMTP server
  • From address
  • Reply-to address
  • Character set

There is no control of the format of the email alert sent, and from I’m told the format is an attached HTML format.

You can also email-enable sharepoint lists, i.e. inbound email integration. This permits someone to send an email to a sharepoint list with content for that list. To use this functionality, you are *required* to install the Microsoft SMTP Server Service. No option to use Exchange for receiving & processing the email. After installing that component, you’ll need to visit the Central Admin > Operations > Topology and Services category > Incoming Email Settings page to configure the farm to use that SMTP service.

After setting the SMTP service up, on the “settings” page for any given list, you should see an additional option under the Communications section, called Incoming Email Settings. You’ll need to give it an email address. The email address has to route to your SMTP service.

If you also want that email address to show up in the Exchange GAL, then you need to get it setup as a contact in Active Directory. There is an option in the central admin configuration to automatically setup these Sharepoint-centric contacts in AD. However, it isn’t clear yet whether there are implications which will prohibit doing this in the NETID domain. It’s possible this could create a situation where a UW NetID account name collision would occur. There’s some further investigation needed on our end here.

Finally, I should mention a few other Exchange integration options. Of course, there’s the offline functionality that Outlook provides. There are several Sharepoint webparts which provide for integration with Exchange-based data. There’s a Exchange OWA webpart, which would allow you to have your Exchange OWA experience within the context of a sharepoint page, subject to whatever configurations you apply to it. There is also an Exchange Calendar webpart, to expose Exchange calendar data on a sharepoint page. Within Outlook 2007, you can access a sharepoint-based calendar, and copy calendar events between any Exchange calendar you have access to and the Sharepoint calendar using an easy drag and drop action.

Sharepoint Resource Links

Here’s a bunch of Sharepoint-related resource links for your reading list. Enjoy!

Bringing Sharepoint Features Together: Content Types Plus Forms Plus Workflows

So in the tools post, I talked a bit about what’s inpidually possible with a InfoPath form and workflows within Sharepoint. In this post, I’d like to look at the combination of using both.

A couple weeks ago, I spent about an hour creating a form and workflow and publishing them on a personal site to get a sense for the experience.

For this demo, I tried to recreate C&C’s Petty Cash reimbursement form and approval process. This form currently is a PDF form which you fill out online, print out, and mail to C&C’s Business office, along with a printout of an approval email from one of eight people within C&C. In other words, the existing process is a mix of high-tech and low-tech. I was aiming for a completely high-tech electronic-based process. I’m sure there are additional pieces of the C&C process for this kind of thing that I neglected–I was simply trying for a concrete proof-of-concept. So as I write about this topic, I’ll add concrete details based on that experience, and I’ve taken a few screenshots to give you an idea of what things look like.

As noted in that prior post, Infopath is both a forms creation tool and a tool for filling out forms, but you can browser-enable infopath forms so clients can use their browser to render and fill out the form. This feature requires Infopath 2007 and the Forms Server component which comes as part of the MOSS enterprise version (you can also get Forms Server as a standalone component).

Infopath has some sample forms you can use as templates. And so I initially tried starting with the ‘expense report’ sample and customizing it. However, I found that there were assumptions nested within the sample that broke as I customized the form. And initially I didn’t know enough to be able to remove all the assumptions to fix the things I was breaking. So I ended up starting with a blank form, however, that didn’t seem to increase the difficulty level. Designing the form was rather simple, with a design task bar that holds all the basic options you’ll likely want. I inserted a table layout, added text box controls, date pickers, a repeating table (for adding an infinite number of itemized expenses), and a button control. I formatted the various text boxes appropriately (some needed to be a decimal data type with a currency formatting), and for some text boxes I put in a default value. On the C&C form, the requestor can be someone other than the claimant, so I made the default value for the requestor’s info be the values from the claimant text boxes. So for the general case where the claimant and requestor are the same, the end user only needs to supply that information within the form once. For the phone textbox, I added a data validation to ensure that input looked like a valid phone number. I did something similar for data validation with the email textbox. For the data textbox, I created a rule. This rule always fires, and has a function which sets today’s date. So that field gets auto-filled out. The experience for creating the rules was similar to that within excel using functions and formulas, i.e. very simple. I could have set the default value as today’s date instead, but I decided I wanted to see how rules worked. Within the repeating table of itemized expenses, I created an total expenses textbox which didn’t accept any user input. Instead it sums all the inpidual expenses. Again this was done using an excel-like formula experience. I also had a textbox for the amount to be reimbursed which defaults to that total expenses value. But the user can override that default value, because they might not be entitled to claim reimbursement for the full cost of some of the items. Finally, I titled the button “submit”. Prior to publishing the form to Sharepoint, I was unable to actually configure the sharepoint-specific actions associated with the button.

Here’s what the form looked like within InfoPath after I was done:

Infopath Form

Once you’ve got a form created, Infopath allows you to save and/or publish your form. You can save it to a file location or to a sharepoint document library. However, the best option is to publish the form to a sharepoint site collection as a new content type. You specify the site collection as the destination for publishing, then choose to create a new content type for your form. The reason this is preferred is three-fold:

  • the form doesn’t show up as an editable item within a document library, and
  • the form can be used on any list logically under that site collection–so it’s more widely usable
  • the end-user experience for starting to fill out a new form makes more sense via this method–from the new menu of the list the user chooses to create a new item of that form content type, instead of opening the saved infopath document and saving it as a new file within the document library

One of the important pieces in the publishing step is to enable the form to be browser-enabled.

So once you’ve published the form as a new content type, you now enable the content type for the sharepoint list within that site collection where you want the forms to be filled out from. That includes the following two steps:

  • From the list > Settings Menu > List Settings > General Settings column > Advanced Settings > Allow management of content types=Yes
  • From the list > Settings Menu > List Settings > Content Types section > Add from existing site content types > select and add new content type

So at this time, the new form content type you’ve added should have resulted in an item on the new menu, like so:

Content Type in New Menu

Once the form has been published to Sharepoint, back in Infopath you can now configure the button action to be submit, and to submit to the sharepoint server. And of course, you need to republish the form again, overwriting the prior version (i.e. the prior content type).

There are a couple gotchas here on the sharepoint list which are probably worth mentioning before moving on to workflow. First, each list needs to be configured to allow browser-enabled documents–this isn’t the default setting. This is the server-side piece of enabling that infopath form to be rendered within a browser. That’s at:

From the list > Settings Menu > List Settings > General Settings column > Advanced Settings > Opening browser-enabled documents=display as web page

And now that we’ve done that, you’ll be happy to see below my form rendered in a browser–and not in IE even, in Firefox:

Browser-enabled Form Rendered in Firefox

Another gotcha is ensuring that your end users have permissions to see and create new items in the list. This may or may not be an issue depending on where the list is in the overall sharepoint site hierarchy.

Moving on to Workflow …

So WSS comes out of the box with a single workflow, Three-State, while MOSS comes with:

  • Collect Signatures
  • Disposition Approval
  • Routing
  • Three-State
  • Routing
  • Approval
  • Translation Management

You may not see all of these workflow options depending on what features have been enabled in the sharepoint farm, and parent site collection.

I chose the Approval workflow, although I suspect a custom workflow might more closely mimic the existing process. Basically, any given C&C person would want to target their director as the initial approver before sending the form along to the C&C Business office. The default Approval workflow only allows you to target a static list of approvers, so that’s not an exact match, but it’s what I went with. I’ll probably investigate custom workflows in the near future.

Anyhow, adding the basic workflows is rather simple (we’ll get to the steps shortly), but you do have a choice of where to configure the workflows. Assuming you’ve added your form as a content type, then you can choose to associate the workflow with the content type. This means that all instances of the form across your site collection will follow that workflow. Alternatively, you can choose to associate a workflow at the list level. I’m going to talk about the latter here, but the former is probably preferred. And you can do both (or have multiple workflows at either level), if there’s reason to have multiple workflows.

For list-based workflows, all the relevant steps are at:
From the list > Settings Menu > List Settings > Permissions and Management column > Workflow Settings > Add a workflow

One of the key pieces here is specifying the task list. Workflows usually generate tasks. These tasks are assigned to the appropriate parties, and usually the workflow does not progress until those parties change the status of their assigned task. So you need to be cognizant of what task list you target your workflow at, and communicate that information to the expected approvers. This is a common gotcha–in the context of this form-based workflow, the approvers will get an email with a link to the form, but the form itself has no approve or reject button. There may be some way to actually add approve/reject buttons that perform that task action, but it’s not a default option. In any event, I’d suggest you include the URL for the task list in the email notification message for the workflow.

Out-of-the-box Workflows can be manually started or automatically started based on item creation/modification. You can configure parallel tasks or serially dependent tasks. You can configure due dates for the tasks, permit the approver to be changed by the initially assigned person, and add a cc for notifying other interested parties.
All in all, the out of the box workflows are very easy to setup. I don’t have a sense yet for whether they have a really wide usefulness, or if custom workflows are going to be much more commonly needed.

I’m still learning about what can be done, but the possibilities are very tantalizing, and I figured this post would be widely useful at exposing the kinds of things that are possible.

Tools for Creating Sharepoint Experiences

Much of this content has previously been posted on the sharepoint_tech list, however, additional content has been added.


There are a variety of tools that can be used to work with sharepoint sites and pages. These tools range from easy to use (with limitations inherent in a simple UI) to very hard to use (with lots of potential). This post introduces the standard options that are available today.

The simplest tool you can use with Sharepoint to create sites and modify them is the browser-based UI–or put another way, no tool required. Via the browser, you can create and delete sites. You can modify sites/pages, modify content within sites/pages, and add new functionality–which in the Sharepoint terminology equates to adding webparts. Adding webparts via the browser UI is incredibly easy, requiring only a couple of clicks, plus any configuration required depending on which of the many webparts you choose. Using the browser UI you can configure workflows, add columns, configure permissions, grant access to the site, configure email-based alerts, and on and on. The browser-based UI is so rich, that the overwhelming majority of Sharepoint users will only ever use this. Because the browser UI is so dominant, it’s easy to mistakenly think Sharepoint has the limitations you experience in that browser UI. It’s a very rich experience, but it doesn’t really extend to the html level of editing. So you can “direct” but not really “design”. Which is a nice segue …

Sharepoint Designer 2007 is the replacement for Frontpage 2003. You can use it with sharepoint or with any website (i.e a non-sharepoint website). However, Designer does have a bunch of functionality specific to Sharepoint. Designer is entry-level tool needed to create master pages, site templates, and custom workflow. You can use Designer to associate a new master page with any page, and create new content regions. Designer can also be used to do most of the things the browser UI allows you to do including editing content, adding webparts, etc. Designer has a very busy UI, with menus, toolbars, floating window panes, and tabs within panes. When following step-by-step directions it can be easy to get lost, as many terms you might use for navigation are used in several places within the UI. As with most computing technology, there is plenty of web and sharepoint terminology “baked” into the experience. Fortunately, most of the folks who are going to need to use Designer will be used to this additional level of complexity. But for those folks who aren’t web developers, you may want to provide some level of orientation.

Microsoft also has the Expressions suite for website design/development which is more of a head to head competition with Dreamweaver. But there is no functionality specific to Sharepoint within that tool suite.

Infopath is the tool to create forms (which can be rendered within any browser). Infopath is both a form creation tool and a tool for filling out forms. So you can get confused as to whether you are filling out the form or in design mode. Prior to Infopath 2007, you had to have infopath in order to fill out an infopath form. This limited the audience to clients on the Windows platform. However, with infopath 2007 you can now choose to browser-enable any infopath form. This allows the form to be rendered and filled out in a browser. Infopath has a rich ability to handle user input and work with it. You can include default values, perform function-based manipulations of data (e.g. sum numbers, do string manipulation, etc.), perform data validation (including regex like pattern matching), apply formatting (e.g. currency), create rules which fire off actions based on conditions, and more. If you have MOSS enterprise version you get the Forms Server component as part of that which allows you to collect and work with submitted forms.

And Visual Studio has always been able to work with websites, Sharepoint or IIS or other. Visual Studio provides access to the full set of framework. In addition, the entire Sharepoint platform has a .net framework behind it (microsoft.sharepoint). So for example, you can create Sharepoint sites from .net code. Or you can extend the existing sharepoint browser UI to expose functionality that’s available but that the sharepoint project team didn’t expose from the default out of the box toolset (this kind of extension is called a “Sharepoint feature”). Visual Studio is required for highly customized workflows, creating your own webparts, and highly customized data control scenarios.

You might also use something like powershell and the sharepoint framework to script common things like site creation. I’ve been told that the Sharepoint framework is not remote-capable, meaning that calls using it must be run from the actual sharepoint server, but I haven’t been able to verify this yet.