SPD Custom Activities are an add-on many people use because they add new custom activities and conditions that can be used in SharePoint Design workflows. SPD Custom Activities give designers the ability to create more complex and powerful workflows without having to know code or use Visual Studio for development. Check out a list of the activities and descriptions here.
These activities have many benefits for users including:
- Make the automation of business processes easier
- Easier to build complex applications without the help of a (costly) developer.
- More power in the hands of the user
- Can quickly prototype, test and deliver applications
- Easier to manage and make changes to applications in production
On the other hand I feel it is important to consider the SPD Custom Activities from a governance and management standpoint. If you are responsible for managing and supporting the SharePoint environment its important to consider not only how these types of solutions will help the user but how will they affect the stability of your environment?
In order to use the custom activities you need SharePoint Designer installed on your workstation and you need at least site owner permissions. Because SharePoint designer is now free any user can get it installed and with the right permissions begin building workflows. With the custom activities it is easier to build more complex workflows. Simple mistakes in the workflow could potentially lead to performance issues (I’ll explain later). It may be best to establish some sort of training for users before they are given access to SharePoint Designer to ensure they have some understanding of workflow best practices. This point applies if you have SPD Custom Activities installed or not even the OOTB workflows can create issues.
Proper Development Practices
Developing workflows in SharePoint Designer is relatively easy and does not require the creator to follow any specific process. Users can easily setup a mission critical application in SharePoint within a few days or weeks. This can make it difficult to support your SharePoint users, here is why. When users can develop complex applications without following SDLC best practices (dev – test – production) it’s easy to have problems in your SharePoint environment without even knowing about them. Additionally as the system owner you may not even know about these applications and their support requirements. When something breaks or the developer leaves how can you support/repair something that was not properly documented or tested. As mentioned earlier these issues are not all specific to SPD custom activities but because of its power can have a larger impact.
Potentially Broad Impact
Workflows are used to automate processes involving large number of items, for processes. If the process only involved a few items users would do it manually through the interface. Poorly-designed automated workflows have the potential to affect large number of items very quickly. SPD Custom Activities adds the ability for these workflows to not only edit permission but also trigger other workflows. When one workflow can start another workflow it’s easy to create a loop that could affect many items very quickly and be hard to troubleshoot as an outsider.
SharePoint can experience performance degradation with a large number of unique security scopes in lists
According to article
“When more than 1,000 security scopes are created for folders or documents in a list, there’s a significant performance degradation in SharePoint operations that badly affects end users operations(rendering content) as well as SharePoint activities like indexing SharePoint Content. After the number of unique security scopes exceeds1,000 per list, SharePoint uses a code path that requires additional SQL round trips to analyze the scopes before rendering a view. When there are 1000 or fewer scopes, only one round trip is required.”
This mainly related to the permissions related activities in SPD Custom Activities. Its true that a user could run into the same problem by manually breaking permissions on many items through the interface however this is unlikely to happen. If a workflow is built improperly and leaves permissions disinherited the process becomes automated. Automating a bad practice is probably not a good idea.
By no means is this post meant to say that SPD custom activities are bad or should not be used. I think they are very useful and can be very helpful when used properly. It’s important to plan ahead and ensure the proper governance is in place to prevent issues like those mentioned above. If you don’t the time or resources to put some sort of governance in place to protect your farm it may be best to do custom workflow development in Visual Studio where it can be properly tested and packaged.