There are huge benefits to be gained by implementing SharePoint Workflow and automation. But to ensure you benefit from them, you need to make sure you’ve established a fully-baked plan before you dive headfirst into architecting and building out your workflow. Take a step back and ask yourself and your team “what do we truly want to accomplish?” and “what do we hope to gain?” These questions will put you in the right mindset to begin each of these major steps:

  1. Identify What you Hope to Accomplish
  2. Understand and Evaluate Your Process
  3. Architect Your Workflow
  4. Plan for Technical Constraints
  5. Design for Analyses

Identify what you hope to accomplish

Establishing your goals will help your team to identify the appropriate process, and likewise, will help you decide if SharePoint is the right tool. As simple as it sounds, it is also going to help you validate that you should be taking on the project to begin with. Start by discussing and understanding your goals.
Objectives

Goals that align well with SharePoint Workflow

  • Improved project visibility
  • Better adherence to timelines
  • More effective prioritization and communication
  • History and timestamping of decisions for auditing purposes
  • Decreased administrative overhead
  • Improved reporting capability

Goals that don’t align well with SharePoint Workflows

  • Highly custom / branded task approval interfaces
  • Approval points that require more than affirmative or negative
  • Systems where more than 1,500 tasks need to be assigned per month
  • Systems where a single flow needs to extend beyond 6 months

There are certainly workarounds for the items that don’t align well. However, if your process relies heavily on any of the misalignments above, consider exploring other tools.

Understand and Evaluate Your Process

Often, we try to recreate what we currently have; there’s a lot of comfort to be had in familiarity. But don’t fall into the trap of “this is how we’ve always done it”, this is your opportunity to streamline and improve! Begin by understanding and evaluating your process.

  • Review your organization’s goals to ensure the process in question is aligned with the future
  • Map the entire process at a high level so that everyone involved can see the big picture
  • Identify the critical parts of the process so that you can focus your attention
  • Identify and remove any unnecessary or low-value elements

After fully reviewing (and hopefully streamlining) your process you should begin to map your workflow and automation elements.

Architect Your Workflow

Now that your team has a good understanding of the process, take the time to think pragmatically about how that translates to a workflow. That is, we need to start thinking about the process in terms of Users, Alerts, Tasks, Actions, and Visibility.

Users

Identifying which user should be taking an action is critically important. A workflow needs to know to whom an email should be sent or a task should be assigned before that action takes place.

  • Should it always go to the same individual?
  • Does it need to go to someone with a certain title in Active Directory?
  • Should it go to a shared mailbox?
  • Can it be assigned to a group of individuals?
  • Do you need to notify external users?

Notifications

A notification is typically sent via email and contains a message and/or link. The purpose is to alert a user or users that an event has either occurred or is about to take place. Typically, a notification is used to communicate milestones or conditions, but does not stop a process or require a response.

Notification examples:

  • The Event begins tomorrow
  • The TPS report has been approved
  • The invoice is past due
  • There has been a change in the record
  • The files have been uploaded

Tasks

A task is an assignment to a user or group of users to take action. Typically in SharePoint, this task can have an “Approval” or a “Rejection”, a due date, and will come with email reminders and notifications. Tasks can also be synced to show up in Outlook’s task pane.

Tasks are typically leveraged to:

  • Approve or Reject a document or decision
  • Request a user to take action and confirm that it has been completed
  • Halt progression of a process until an action has taken place
  • Log the date, time, and individual taking action on a task

Automation

When certain actions take place, or certain conditions are met, SharePoint workflow can take actions on your behalf. SharePoint comes with a broad range of actions it can take on your behalf right out of the box. For example:

  • Create, Update, Edit, or Delete an item
  • Do a calculation
  • Send an Email
  • Assign a task
  • Wait for a Date or Event
  • Call an HTTP Web Service

Because there are often things we want to automate that don’t come out of the box, the ability to call an HTTP Web Service is the most powerful. Using that, a developer can build or communicate with a freestanding application that lets you extend functionality and interact with other systems and software.

Beware of Information Overload

Take great care when identifying key points in your process to determine where visibility or engagement is critical. It is all too easy to create a workflow that automates a process and inundates its users with an inordinate number of emails. Focus on only the alerts that add value to the process. For example, you may want to set a management alert when a group of tasks have been completed or when they’re in danger of missing a deadline vs. sending an alert blindly each time a task is complete.

Plan for Technical Constraints

As with any software development, a SharePoint Workflow must be planned defensively to avoid common pitfalls and limitations. Most of the more troublesome limitations can be avoided with good up-front architecture and integration with Azure or other database resources.

Workflow history deletion

SharePoint cleans up after itself, deleting the history of task approvals and timestamps within 60 days of workflow completion. This prevents the list that contains the data from exceeding limits, but is bad news if you need to report on that data in the future. Consider copying this data to a persistent location such as SQL Azure at workflow completion to build a repository of approval / rejection history.

5,000 Item List Limits

SharePoint limits lists (specifically views of lists) to 5,000 records. This means that if you’re going to have more than 5,000 tasks issued in a period of 60 days + (the length of your workflow/process), you’ll need to identify a way to record the history and clear tasks. If you’re looking at a process that requires far more than this, SharePoint may not be the right choice.

Similarly, this also means that each instance of your process needs a means by which it can be archived. Even at low throughput, it’s likely that you’ll eventually exceed 5,000 items. As such, you need to think through how you want to keep that number below 5,000.

Keep Workflows Short

If a workflow can logically be broken into several smaller workflows, take advantage of it. This allows for a more dynamic experience and doesn’t lock the values into variables until the last possible moment. From a defensive development perspective, if the workflow does encounter an error, that error only applies to a small piece of the workflow instead of the entire process.

Minimally Customizable Task Interactions

SharePoint does a great job at providing everything you need to approve and reject tasks out of the box. If you need to add comments or rejection reasons to tasks, that’s fairly easy to extend as well. However, SharePoint is not geared toward providing custom responses beyond Accept and Reject. It’s possible, but along with it comes significant development and maintenance costs. If the majority of your tasks can’t be quantified as Accepted or Rejected, you may need to look for a more customizable solution.

Design for Analyses

Along with the tasks and history log of the workflow comes approval outcomes, timestamps, and a record of users taking action on these items. This information is great from an operations perspective, but there’s even more value from a business intelligence perspective. Once you have a chunk of this process data to work with, you can begin to analyze critical metrics and learn more about your processes. For example:

  • What types of projects miss deadlines?
  • Which employees do well at which process?
  • Where can you add efficiency?

By thinking through this upfront, you can ensure you’re capturing the necessary data points. Using SSRS or PowerBI, you can turn that analytical data into visual reports that are easily consumable by business management.

Summary

There’s ton to be gained by adding automation and workflow to support your processes. With the right attention and investment in upfront planning, you’ll get a reliable solution that does far more for your business that just “automating” a process.

In this post I’ll be going over the various advanced custom code and configurations you can apply to the Sitefinity content editor along with tips and tricks to wrangle the admin the way you need it so it can perform at the optimal level for your client.

Warning: It’s highly suggested if you haven’t already read Part I of this series that you go back and do so. You can view that post here.

Cool Custom Textbox! Now what…

So we left off last time creating our very own custom field in code using Sitefinity Thunder and inserting it into a Sitefinity Content Editor. As of right now you’re thinking, “but it’s just a text box,” but that’s the starter-set for an entire custom field collection. Almost every custom field type will start as a custom text box created in Sitefinity Thunder. From there we can mold it into whatever we wish.

Outside the textbox, I find one of the most common form inputs to be the good ol’ fashion dropdown. Most of this blog piece will cover the code intricacies of our newly created custom textbox and how we will fashion it into a full-fledged, data-driven dropdown that saves selections in our content form to the database.

For your viewing pleasure I’ve attached the field and its files here you can follow along at home if you like. Keep in mind it in order to toss the same code into one of your existing projects you’ll probably need to adjust some namespaces, otherwise it should make a great reference for your future custom fields.

DemoField.zip

What’s in the box…

Let’s go ahead take a look at the code files generated from Sitefinity Thunder. There are six files altogether, three of which you’ll generally do most of your coding in. Depending on what you named your field, it generates a like-named ASCX, .CS, and .JS file that gets created along with three Definition .cs files, which we won’t be changing; these mostly control elements that are already editable in the WIZYWIG and it’s generally unnecessary to alter.

Demo Field view

DIVE! DIVE! DIVE!

Let start with the simplest file, the .ASCX. Like any custom user controls created as widgets, this is the “face” of our field. You can see our pre-generated Text Box, “fieldBox”, along with a description and example label. These objects are fed information on page load from the accompanying .CS file.

Demo Field CS page

Tip/Trick: For you interfaces out there: I found classes and styles work generally the same as they would on any other .ASCX page, however, I suggest linking to specific css files as the field tends to not find layout and master page references due to the nature of the admin (I suggest a separate CSS for the admin altogether anyways). Putting this on the page, For Example, will usually do the trick:

<link href="/Sitefinity/WebsiteTemplates/HWH_Desk/App_Themes/Styles/CSS/AdminEvents.css" rel="stylesheet" type="text/css" />

Before moving on to the .CS, let’s go ahead and make that an ASP drop-down as we won’t need to change anything else here later. Take notice I added the “ClientIDMode=’Static’” attribute. This will come into play further down the road, but ideally we want to know exactly what our dropdown’s id will be in the DOM, otherwise ASP.NET will generate a unique one for it (which for custom love later on is not what we want). If you plan on making a custom field “Template” that you plan on using multiple times, stick with the Client Generated ID, otherwise I think you’ll find doing this for all your truly custom fields will be a major stress-reliever later on.

Code Snippet

OK, now for the meat and potatoes, the .CS. There’s nothing too crazy going on here, you have properties being defined for the ASCX controls, methods for initializing and populating said controls, Script Descriptors/References for the .JS files, and some file path references (these you would most likely change if we we’re trying to implement a 3rd party custom field).

Let’s take a look at the generated properties. You can see the ExampleLabel and DescriptionLabel shorthand setter/getters, which we don’t want to change as they work perfectly fine, but we need to replace the textbox because clearly it will no longer exist in the ASCX.

Generated Properties Code

Also, check out the override Object “Value”. This is the Value that Sitefinity saves into its database to handle the custom field, whether it’s a short-text string, int, decimal, you name it. This is what you’ll be setting your controls value to. Let’s go ahead and replace that Text Box with a Drop Down.

Code snippet

Ok, the fun part. Let’s populate our drop down with some data! Just below our new DropDownList property you’ll see an override method for InitializeControls. This is where we’ll populate our dropdown.

DropDownList Property Code

So let’s go ahead and add a simple set of hardcoded choices and map out some values to populate with for demo purposes. Keep in mind you can save any value type to the database (in this case I’m using an int value) just be sure to select the appropriate value when you register your field control in Sitefinity.

Code snippets

Before moving onto the script file we need to map descriptors for it. You can see now that the TextBox property has been removed it’ll throw an error, we need to update it.

Code Snippet

Take note of the name-change to “dropDownElement”, we’ll use that later in the .JS file. Also see that instead of ClientID we map to the normal ID as noted in a previous page.

code snippet

Ok the last piece, the .JS File. Sitefinity uses these files to load in save/load commands as well as logic to be used in the DOM for their particular custom pieces. The .CS file that loads the data and Value for the custom fields doesn’t actually save or manage it, the .JS file does. This is also the piece where we can manage modal editors should we need to (like a file selector) before processing the form request. From there content items are saved and managed by a specific Decorator Event Class (which we’ll talk about in part III).

Unfortunately, this isn’t a very intuitive or easy-to-use exchange process and I suggest trying not to muck around in it too much unless you’re very familiar with the system and of course JavaScript. Luckily for simple items like this we just need to update the element property name to that of the appropriate script Descriptor, “dropDownElement”.

code snippets

Go ahead and replace all the “textBoxElement” values to make the script kosher with the rest of the code base. Keep in mind, if you needed to rename your namespace there are several (at least 8) items to rename here.

Show Time!

Ok we’re ready to register our new dropdown. Like in part I, go ahead and register your project, this time as an int value.

Admin view

Once you’ve filled out the appropriate fields and labels to the custom fields sections your dropdown will appear and be ready to go in your Sitefinity content type.

Admin Dropdown view

All that for a drop down?

Yes for demo purposes we stuck with just a hard-coded dropdown, but what you’re really doing is integrating a new ‘Type’ into the Content Admin. This can be more than just a dropdown but any cross-type integration. For instance, we recently integrated Intellipad and Constant Contacts CRM systems into one of our client’s Sitefinity Event Content, effectively mapping the three together with Sitefinity as its hub using custom dropdowns. Here’s a little taste:

Code Snippet

Say instead of that hardcoded list we pull in a direct list of the clients mailing lists through CC’s API. You can then create another drop down for “Email Campaigns” and include a button on the ASCX for the custom fields. On click you can kick off a service call to create email campaigns and call lists based on people that signed up for this particular Sitefinity Event. Remember when I had you set those ID’s as static? Well the different fields can ‘talk’ to each other by using scripts that look for their fellow form-mate’s selected values. These functions can live right on the ASCX pages along with the inputs and collaborate together for powerful functionality like create emails for mailing lists from right within the form, all without even posting back.

Admin View

Admin view

From a styling standpoint you can take this a step further too. As mentioned earlier in the article, styles can be linked in the individual forms to style individual custom pieces, but you may want to arrange them in a format that better suits your admin as opposed to how Sitefinity displays it. You can move these items by altering the live .config files associated with the content in the configuration folder of the App_Data/Sitefinity folder in the project (where the data config lives). After a custom field is added for the first time these files will be generated and will allow you to move around and style your fields to your liking.

Code Snippet

Note: the different ‘view’ types. This will allow you to separate how your fields are visible depending on the action of the content. For instance wanting to hide certain fields on object creation that would only make sense during an update process. Simply ‘arranging’ the fields in the xml will allow you move fields around, even in the following example into more manageable accordions if you desire to style such.

Code snippet
Admin view

One thing to note about this is it can be tedious as Sitefinity writes to these files any time you alter custom fields, so I suggest waiting to style the frame of your fields until after you’re done creating them. Once you’ve made your swapping and arranging you can get a much neater admin.

Almost there…

It takes some experimenting, but the advanced custom field creation and styling can bring a lot of exciting new prospects to a once seemingly rigid structure that is the Sitefinity Content Admin. It can also be time consuming, so be sure to be ready for long haul; just keep in mind it’s certainly worth the client’s greatly improved experience in the end.

In my next blog piece, I’ll be talking about Event Decorators and how they allow you to handle many qualities of the Sitefinity Content process on post-back of the admin content management process; including custom data and event handling, task management, and more.