SimpleChart (Org Chart WebPart) For SharePoint V2 – Now With Active Directory

I had some time over my lunch break today to put in a lot of fixes, code improvements, and new features. In no particular order of importance, there were three big things done:

Code Improvements I added improved exception handling, principally for resolving particular Types of exceptions, avoiding the use of a catch all Exception type. Beyond that, bloat reduction and reuse in terms of static method extraction, general refactoring, etc.


Exceedingly generic methods are used for everything non-specific to the gathering of the org chart data, such as major rendering methods since values in a DataTable (according to Google Visualization API specifications) are really the only thing changing.

General Fixes With The Last Version People were getting an ArgumentException bubble up in the last version that occurred on particular SharePoint patch levels. This has been mended in this version. It was my fault; I only had one platform to test with at the time because I wrote the first version over a lunch break at a client. But hey, it was labeled in the versioning output as a checked/debug build. :)

Active Directory Integration Yea! This version offers a toggling in the WebPart properties allowing a user to specify which mode they want to run SimpleChart in, either SharePointListMode or ActiveDirectoryMode. Each of these requires the hydration of their relevant properties, i.e. SharePointListMode requires the appropriate SharePoint List and Column Values, and ActiveDirectoryMode requires knowing which domain to query against. I added the Group Restriction option as a property because just laying out a domain in an org chart is frankly ludicrous. For any reasonably sized organization that would hardly be useful. However, it is prevalent within orthodox organizations to have Active Directory groups that are representative of divisions or other logical groupings within a company so this seemed like the most practical approach.

So, for those that like exhaustive illustrations before they download something, here is the WebPart in action.

Firstly, let’s start using SharePoint lists as a datasource follows the same pattern that is detailed in the first version of this WebPart here. That post has the solution install instructions so I am not going to rehash that.

When you first add the WebPart, the default mode it will function in is SharePointListMode. You will be informed that the required properties for the WebPart to function have not been adequately provided.


So you have to go fill these in! For this exercise I am using the SharePoint List Template (.stp) as detailed in the last version post as a datasource since it already has the relevant values for testing. When you open the properties, make sure you got the right version deployed by examining the versioning editor part located at the top of pane. Your version should be **.


Going off that same template, im going to make a new list off it:



Then fill in all the relevant properties for normal functioning based on the list data source. Same as last version, nothing fancy here. Remember to put the list name in too even though the below is simply showing the column hydration for brevity reasons.


When completed, you will see the org chart rendered! You just made art. Kinda.


Now it’s time to demonstrate the Active Directory integration. Firstly, you have to examine the new properties that allow the org chart to render out correctly.

  1. Specifies the rendering mode, whether you want the org chart to target either a SharePoint list or an Active Directory data source.
  2. This is still the list to use when in SharePointListMode.
  3. The domain to query into when using Active Directory mode.
  4. The name of the group to restrict the org chart to. This can be a division, grouping, anything really. This allows several org charts to be tailored to specific divisional taxonomy’s rather than making a master domain org chart that provides literally zero value. Unless you have like 5 people in your company.


Firstly, change the rendering mode to use ActiveDirectoryMode.


Now fill in the remainder of the properties based on your environment.


The group you choose is pretty flexible. Since I am using the Microsoft provided VM I am actually going to change “Guests” t0  “Litware Contractors”. That only has two people so should cultivate a nominal display.


Now, mapping the name in the WebPart properties:


 And now displaying the sexiness that is esoteric business material, the resulting org chart:


And that’s it! The WebPart is free, but any backlinks or examples of your use, even in the comments, is always neat because it equates to my satisfaction as a developer.


Let me know if you have problems in the comments :)


Using the KeywordQuery Class to Get a List of Department Employees

Along the same lines as this post, once one has located the relevant department that they desire from a collection, how is it possible to use that department string name in order to get a list of the relevant employees? As we used the KeywordQuery class the last time, we are going to take the same approach in order to return a new DataTable with those values.

Here is the code in order to execute that:

public static DataTable BuildDepartmentEmployees(string url, string deptName, int queryLimit)
using (var result  = new DataTable())
using (var site = new SPSite(url))
using (var query = new KeywordQuery(site))
query.ResultTypes = ResultType.RelevantResults;
query.EnableStemming = true;
query.TrimDuplicates = true;
query.StartRow = 0;
query.RowLimit = queryLimit;
string str =
query.QueryText = string.Format(“scope:\”{0}\””, “people”) + string.Format(” department:\”{0}\””, deptName);
query.SortList.Add(“Rank”, SortDirection.Ascending);
using (ResultTable reader = query.Execute()[ResultType.RelevantResults])
result.Load(reader, LoadOption.OverwriteChanges);
return result;