Disabling the Status Message field
Removing the Control
A colleague of mine was asking for a comprehensive list of available workflow actions in SharePoint Designer 2010. I did some searches and couldn’t find the details so I thought I would provide them here.
I was disappointed to report that there is still no out of the box action for calling a Web Service or action to bring back other attributes of the User’s Profile. Custom or Third-Party actions will still have to be used to support this.
The workflow features first introduced in WSS 3.0/MOSS in 2007 and enhanced in the 2010 offerings present an opportunity for organizations with SharePoint to start to automate the coordination of their business processes. While many have been working with it, one of the limitations I have seen is that everything is localized to a particular site or process. In many cases there are configuration or user attributes managed in a local list that can be used as a data source.
One technique that is not widely used, but could greatly enhance the capabilities and manageability of the workflows as a whole would be to utilize the User Profiles more to house and maintain information relating to the users. By managing it centrally it can be used by all processes throughout the organization. For user maintained properties, it provides a central and secure mechanism for them to maintain it. For system maintained properties, synchronized from an external system through AD or the BCS (HRIS, CRM, etc) there are already mechanisms in place to manage this.
In SharePoint Designer 2010 there is a new action that supports a lookup for a user’s manager. This would be a critical component to support approval workflows obviously, but for most business processes there are other attributes that are also needed. Some could be based on default user profile fields like Location or Hire Date, but others are likely to be custom to the organization. Custom properties could include employee IDs, department charge codes, division identification, etc. [Note: See User Profiles – Creating Custom Properties for a walk through]
InfoPath – From InfoPath you can identify a DataSource through a Web Service call pointing to the UserProfileService. [Note: See Itay Shakury’s blog for full walk through]
Visual Studio Workflows – In visual studio with the full ASP.NET capabilities it is easiest and most effective to use the UserProfileManager to access the profile and all properties.
SharePoint Designer Workflows – With the exception of the manager lookup action that was added, SharePoint Designer workflows will need either a custom or third party action that can interact with the User Profiles.
I am currently working on a simple action that I will blog about and post to CodePlex.
This process could also be used to provide a mechanism for maintaining additional, more complex properties. An example would be something like Delegation of Authority which allows a person of authority to be able to delegate (or pass) that responsibility to another person. SharePoint does not handle this at all out of the box. A series of fields could be defined to support this; Start Date, End Date, Delegate. This information could be read into the discrete processes with management being centralized in the User Profiles.
The limitation with this model is that the User Profiles are not like a list and do not support advanced business rules. If that is required a separate system would need to be build, but I would recommend you try and keep it centralized and not built into the specific process.
By leveraging the User Profiles as a central repository that can support your organization’s processes you will simplify the management of the information and make it much easier to reuse in a consistent manner across the many processes.
One of the areas I continue to see companies struggle with is sharing and reusing content. Many will cram everything into a single site collection, or worse yet a single web so that everything is in one spot and available. A little over a year ago I wrote an article titled “The Importance of a Content Syndication and Aggregation Plan” where I covered a few of the method used in the 2007 version. There were a lot of limitations with the out of the box toolset, many relating to the site topology boundaries. The 2010 version brings a few important improvements that I think will benefit most companies.
Things are vastly improved in 2010. All of the features from 2007 are still available, and some of them have been improved. They include:
Some of the new features include:
Calendar Overlays – One of the most common requests I have received in the past is to aggregate multiple calendars. Whether it is for doing a roll-up on the teams or groups in a department or for pulling together dates across multiple projects, people need to be able to merge calendars. With 2010 you now have the ability to aggregate up to ten calendars in a single view. These calendars can be in any site collection, and can even be from exchange. This makes it super easy for example to pull together a main company calendar with the entries being managed by different departments like HR and Marketing or across divisions.
Check out Bjorn Furuknap’s blog for details. He did a great walkthrough on how to View Multiple Calendars in SharePoint 2010 here.
Managed Metadata Service – As the name suggests, this is a centralized service that enables you to manage your terms and content types. Previously Content Types were bound to a specific site collection and working with them in more than one site collection meant manually keeping them in sync. Having content described consistently across an organization makes aggregating that content a whole lot easier.
Here is the documentation on TechNet for the Managed Metadata Service.
An important word of caution; just because a feature is supported does not mean it will meet your needs. In previous versions some of the aggregation features that were available, like the ability to connect to another list in the site collection with a DVWP or CQWP, worked fine when working with a few data sources but did not scale well. I have heard of cases where hundreds of data sources need to be aggregated into a central source. Be sure to perform both functional and performance testing to ensure that it meets your needs and if not, look to a custom solution that fine tune the process and perhaps implement a special caching mechanism.
As part of the site topology planning or review, it is important to think about the content that will be stored and where else it might need to be used. Make sure that the team is familiar with the different aggregation or roll-up options and what the pros and cons are to each.
Microsoft’s technology stack has traditionally offered a lot of good options leaving the developer or architects to choose the best path. Even still there there have been people camping out on one side or the other. In the early days when VB first came out the hardcore devs didn’t take it seriously, and I remember hearing a lot of negative comments from traditional C++ developers. VB devs didn’t have to understand concepts like threading and memory allocation and the VB code was bloated leading to “poor performance.” While those statements are true, not every deliverable has the same grade requirements and in many cases businesses were more than happy with the code that was delivered faster and for less money than what C++ developers could provide. I think this is a very good analogy to the current SharePoint development and customization paths. Microsoft has worked hard to position SharePoint as a tool that can be leveraged and customized by power users as well as developers. I think this is both a strength and a weakness; a strength because there are options, but a weakness because many of the people doing the work do not understand the implications of their decisions.
The first thing I think about when I get a request is the scope of the solution. I think through the questions below and choose a direction that makes sense in order to meet the requirements in a cost effective manner.
Who is the audience? – The larger the scope of the audience, the more robust the solution should be. A solution created for a work group is probably very different than one used enterprise wide.
How many users will need to use it? – Similar to the previous question, but a little more concrete. Do you expect 10 concurrent users, 100 or 1000? Company or enterprise wide means different things in different environments.
Where will the solution be used? – Deploying the solution on a single Project or Team Site is very different than deploying it to 100 sites, which is very different than deploying to the front page of a company’s Intranet. If it is for a single use the Light Dev and Customization path can make sense. If it is meant to be reusable, then it warrants more time and attention to make sure that it is the best it can be. If it is use on a top level or heavily used page or site then performance is even more critical meaning a more robust solution should be developed.
How long is it expected to be in use? – Try to have some understanding of how long the solution is intended to live. Assumptions may change, but make an informed decision based on the information you have at the time. If a newly acquired third party tool will be providing that functionality in the next 10-12 months there is no need to overbuild the solution. Likewise, don’t take short cuts on a critical project that can undermine peoples’ understanding of the capabilities of the platform.
Who will maintain the solution? – This is a tricky one. Not every company has a large staff of qualified developers waiting in the wings. There is normally a large backlog of work waiting for them. If you are a consultant then you might look at whether you are handing over the support to the internal team or if your group will continue to maintain it. The group isn’t capable of maintaining a solution and doesn’t have the tools and environment in place to do the work then full scale development may be a bad idea.
Are there performance requirements? – If there are performance requirements then those should be planned for from the start. Stats like page load times, and an agreement on what constitutes the end of a page load are important. In most cases I have not seen this requirement.
Light development and customization includes features and solutions dealing with SharePoint Designer, DataViews, Content Query Web Part and the Content Editor Web.
More than anything I see this being for the benefit of Power Users and site owners who can apply customizations within the scope of a site collection. While there are many that want to outlaw SharePoint Designer and these solutions in their environment, I think they risk eroding the value and impact of their SharePoint platform. I see SharePoint as a tool that enables content/site owners without needing to rely on a central IT group.
I tend focus on this part of the stack when dealing with solutions targeted to small teams or with small requests that do not need a full blown application. There are definitely lots of opportunities for simple, high impact, one off solutions.
This however is probably not the appropriate set of tools for org wide workflows, complicated forms, or even displays on heavily trafficked pages. The Content Query Web Part (CQWP) for example is not the most efficient way to aggregate content so pulling something like project status information from 50+ project sub-sites is likely to end in frustration.
Robust development includes features and solutions dealing with Visual Studio built applications packaged and deployed via the solution framework in SharePoint.
This really should be the starting point when reviewing any project of real significance. The developer has a lot more flexibility and control in what can be implemented and it is much easier to centrally track and manage what is deployed to the server.
I think that it is important to note that poorly developed VS solutions are at least as dangerous as anything that can be done using the Light Development and Customization technologies and techniques. Failing to dispose of objects or inappropriate CAML queries can bring down a server or cause all kinds of havoc.
There will be times when it is necessary to blend the two approaches. Within a given project there are features that are core to the solution and some that are in more of a supporting role. Admin or reporting features are a good example of that, where using a DataView may be easier to maintain than a custom Web Part to display content.
Customers, project stakeholders, and other decision makers do not always know what is best. I’ve seen many cases where even sophisticated development shops do not fully understand SharePoint development paths and fully leave the decision up to the developer. Like any project using any technology, risks should be identified and discussed before things get too far. It is irresponsible to deliver a solution that you know cannot be supported or maintained after you sneak out the back door at the end of the engagement.
From an administration perspective, I do not want to manage more solutions than I need to. There is a balance between wanting to know what is deployed to the environment and wanting to touch everything that is installed. If there is a fairly ridged change control process in place it can be time consuming to submit and deploy minor updates to small, narrowly scoped solutions. Again, my approach comes back to the scope of the solution preferring to focus on widely scoped, high impact solutions.
As we inch closer to SharePoint 2010 and the vast improvements made to the My Sites feature set I thought it might be time to revisit some key concepts when looking to leverage My Sites in an organization. In many organizations I see My Sites as still under deployed and under utilized. In some cases it is because leaders do not know what to do with it while in others they are not sure how to support it. I hope to address both of those issues here along with offering some other advice. By addressing the topic now I hope that business can get a jump on implementing the tools based on the current technology as well as bring it to the forefront of the 2010 upgrade planning so that they will be able to better leverage the tools in the years to come.
In its simplest form, My Site is a SharePoint site collection owned by an individual giving them the ability to have both personal and shared content. It also includes the bases for many personalization features including a Colleague tracker, My Links, and the ability to aggregate content like tasks and documents they are involved with throughout the entire farm. Since the sites can be automatically provisioned in most environments it takes little or no IT interaction for a user to get started.
In some environments the the feature is limited to IT and some power users, while in others the service is available but its benefits have never been communicated to the organization as a whole. By widening the audience and its participants more value can be derived from the tools.
These tools are a good foundation for an Enterprise 2.0 strategy helping your users find and communicate with each other. In most organizations people are already using these types of tools, but they are doing it for different purposes and with tools hosted outside your company’s network. Look at LinkedIn, Facebook, and Twitter which probably already have unofficial groups or networks organized around your company. By pulling some of this into your network you can expand productivity around internal information assets, provide some level of information security, and increase the overall socialization activities.
In a recent post I wrote about Overcoming Obstacles in SharePoint and Ent 2.0 which addresses a few of the biggest issues; Fear of Change, Information Power, and Lack of Interest.
Like most SharePoint topics we cannot have a full discussion without mentioning Governance. Oddly enough, this is one area that I think perhaps can be over governed. The cornerstone to Social Computing is social interactions and for it to be social there needs to be room for an individual’s creativity. That isn’t to say that anything goes, but in many cases things should be generalized into more of an appropriate use policy.
Personal Photo – One of the most personal aspects of personal computing is the individual’s photo or avatar. Hopefully within an organization people feel comfortable enough to have a photo or at least an avatar. While a photo of the person is great it probably shouldn’t be a requirement and hopefully isn’t their mug shot from the badge or security system.
Dressing up the My Site – The individual should be allowed to change the theme to personalize the color scheme and select a personal icon or banner for the site. Even if the rest of the SharePoint sites are fully branded with the corporate identity, small things like this can really increase the interest level since it gives them a chance to be creative and truly gives them ownership of the site.
Quotas – Quotas should be set at a reasonable amount. Too little and users will end up going back to Shared Drives which will undermine use of the tool. Of course too much and there is the possibility that storage costs can escalate quickly along with backup and recovery times.
If used appropriately it should draw down the storage requirements in email and shared drive storage thereby just shifting storage from one system to another.
SharePoint 2010 will add in both the Facebook “Wall” concept as well as some enhanced social bookmarking, both of which have been painfully missing from the 2007 offering.
While both of those features are welcomed additions, there are more opportunities to extend the system as well. One of the things I like best about systems like Facebook and LinkedIn is there are all kinds of tools that have been created to help interact with the platforms. This includes everything from mobile browsers to make posting updates easier to the LinkedIn Outlook Toolbar that can expose user’s LinkedIn profile, status, and network information in Outlook. The Outlook team has responded by offering the Outlook Social Connector which promises to offer an extensible provider platform for integrating with multiple social platforms including SharePoint 2010 as well as Windows Live and anyone else that can create a provider.
Other extensions and tools are still needed though. In the past I wrote a bookmarking component that supported adding items to My Links from both inside of SharePoint as well as other ASP.NET applications. As soon as I get a handle on the final features of SharePoint 2010 I plan on updating that and making it available as a project on CodePlex.
Simple content components like a Quote of the Day or slide shows can also increase the personalization of the system.
This is for business, but it can still be fun. Increasing the fun factor will get people to be more engaged and interactive. Also, it is a proven fact that teams that know each other at a personal level and can maintain relationships function at a higher level.
The cloud debate continues to rage in the offices of many business and IT executives. They look for it as a way to control or reduce costs and to better focus on their core business functions instead of managing complex IT systems. As a technologist though I see the cost benefit not just in dollars but in opportunity and the potential for the system to enable the organization to innovate and collaborate in ways they were not able to in the past.
I see plenty of value in SaaS for commodity systems, with email being a great example of that. Email systems both large and small can be expensive to run and there can be very little difference in the service if it is run in house or in the cloud. Is SharePoint a commodity system though? Certainly some organizations are doing their best to not customize it. Last year’s AIIM survey results reported many organizations underestimating the cost and effort to customization and integration which I’m sure will scare executives of any new implementations. As a developer and integrator I have seen tremendous valued gained from implementations that are extended to work with other enterprise tools whether it is an ERP, HRIS, CRM, ECM or 3rd party BPM/Workflow systems. The level of effort to implement and maintain those environments does need to be included in the decision process. The cost is significantly higher than a vanilla SharePoint implementation so the value derived should also be measurably higher.
If it is a plain vanilla environment then it is a great candidate for SaaS including MS Online. The new “Sandbox” feature of SharePoint 2010 may help to provide a mechanism for minor customizations and an “App Store” that could benefit users of a hosted SharePoint environment. This should definitely simplify the process for making some customizations possible.
It will be interesting to see how the SaaS and hosted solutions evolve over the next few years and how they are perceived by organizations. It will also be interesting to see if the Sandbox feature is made available to those services and what kinds of solutions are made available through that interface.