Over the last few days I have been looking at Workflows in the Enterprise Edition environment, after they were very limited in the Small Business Edition. I started by creating a reusable workflow, that can be applied to almost any list or document library. This workflow would allow users to request annual leave, the workflow would then get their line manager to approve or deny the request. This worked very well, and did what I expected it to. After accomplishing this Rob and I decided to add more functionality, which would add the leave (if approved) to the corporate calendar. At this point I discovered that the workflow would need to be associated with a specific list to enable it to obtain all the fields within the Annual Leave list. This time I recreated the workflow as a list workflow and selected the list to associate it with. I could now access the required fields to add the approved request to the corporate calendar. However upon testing the workflow, it stopped at a certain point and returned an error. Below is the workflow that has been created, and the sections in red appear to be causing the problem, this process does start though as an email is sent to the initiator to say this.
I have been trying to find a solution to the problem, but so far have been unsuccessful. I have discovered though, that the workflow may need to be split in to two. When the workflow is initiated, it runs under the permissions of that user, which will not likely have permission to approve items. I will be looking at this soon too.
After submitting a service request to Microsoft, I have this morning (17/10/2011) been contacted by a representative, who has taken me through some troubleshooting. Throughout this he took screenshots to enable the process to be recreated, to try and identify the problem. A solution is expected on Wednesday.
The representative from Microsoft has since been in touch to inform us that he is still working on the problem. A solution is expected any day now.
We now have access to an extended trial of Microsoft Office 365 Enterprise Edition. This will now enable us to actively use and test features of the service that the University may upgrade to in the near future. We will now begin to look at complex workflows, integrating InfoPath Forms, and RSS Feeds amongst others. In a just couple of days we have managed to give the site some basic branding, after coming across many difficulties trying the same thing in the Small Business Edition. As always we will keep posting with our progress.
I have been working with Microsoft Office 365 Small Business version for 2 months now and I believe we have pretty much reached its limits.
As we are currently leaving migration until we are both back from our holiday we have been looking into more features of Microsoft office 365 that we might have previously missed, features such as RSS feeds, target audiences, info path lists, complex workflows and more. None of these appear to work in the small business edition, there appear to be a huge amount of restrictions that only allow us to do the simplest of task (no IT pro required). For us to continue with Microsoft Office 365 I believe we need to upgrade to the Enterprise edition, this will allow us to test features that may actually be useful to the University, it will also allow us to use features that even SharePoint 2003 currently use, such as target audience. To me, I believe that even Office 365 Small Business should be an improvement on SharePoint 2003 and not hold features back that would put 2003 ahead of small business.
So after we have looking into migration more closely and tested some of this, I believe we have no choice but to move up to Microsoft Office 365 Enterprise edition, so we can test these useful features.
Single Sign On is a really useful tool to save users having multiple usernames and passwords and enables them to use their corporate login details for other services. Single Sign On is not available with the Small Business version of Office 365, but is available with Enterprise versions. Single Sign On has many benefits, including, policy control, access control, reduced support calls, security and support for strong authentication.
To use single sign on you must:
- Have active directory deployed and running Windows Server 2003, 2008 or 2008 R2.
- Install all required updates for Office 365 from Microsoft.
- Use the Microsoft Online Services Module for Windows Powershell to establish a trust with Office 365.
- Plan for and deploy AD FS 2.0 on Windows Server 2008 or 2008 R2.
The full article for preparing Office 365 and Single Sign On can be found here: http://onlinehelp.microsoft.com/en-us/Office365-enterprises/ff652540.aspx
Another more in depth article can be found here: http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652539.aspx