So you only need 1 slot per state approval and you have multiple destinations for each state (Jim, John).   Depends on how many users you have, you could probably get away of using String Tables to store the members if you don't want to deal with external table & lookup.

Name string value   NJ_USER1 with value JIM's domain/ID (if you have multiple domains), then NJ_USER2 with value John's ID.   In the destination rule you could use try catch and NJ_USER & iloop to increment one by one.  

This method doesn't give you the best view on how many states a specific person is handling, but you could query the K2 table on string table to sort it if you needed to. 

You don't need to create 50 active directory groups if you assign the person explicitly. (but you do lose the dynamic changes, which I don't think happens often in your case?)

My previous method of using string table allows you to update the users w/o having to export the process again.

Hi,

With respect: I don't think StringTables are the best option in this case, StringTables should only be used to store Process Configuration parameters.

Your best bet would be to store the State to User assignments in your own SQL table(s) and then write a web service which takes a state as input and returns an XML string of users for that state, this will even work if you have more than one responsible user per state.

Use Code in the destination rule to call the web service and iterate through the repeating nodes, adding a K2 destination on each iteration. Here is an example:

 if (oDest2.IsSuccess == true)
 {
 //== sendto ALL Regional Approvers
     System.Xml.XmlDocument myXApprovers = new System.Xml.XmlDocument();
       System.Xml.XmlNode myXNode;
       myXApprovers.LoadXml(K2.ProcessInstance.XmlFieldss"Approvers"].Value);
       myXNode = myXApprovers.SelectSingleNode("approvers");
       if (myXNode.HasChildNodes)
       {
          foreach (System.Xml.XmlNode myXChild in myXNode.ChildNodes)
          {
    K2.Destinations.Add(DestinationType.User, myXChild.SelectSingleNode("SAMAccount").InnerXml);             
          }
       }
  else
  {
   K2.Destinations.Add(DestinationType.Queue, "FallBackRole");
  }
     if (bAllTrue == false) return;
 }

Regards

 Deon

Yeah - storing the user/groups in our own sql tables and using our own component to retrieve the appropriate users is the route we were thinking of going.  I should be able to create my own assembly and reference it in the code, right?

Thanks for the help.

Sure, you can call any assembly or web service directly from the Destination Rule Code.

-D

Hi bdoc7k2,

It’s always a interesting question on what is 'clean' approach to business logic. The answer is party based on opinion and partly based on other non-functional requirements. Some things to consider are:

• 
  
• maintainability (how easy should it be and by whom)
  
  
• maintenance interface (where should the maintenance take place)
  
  
• complexity of you code and how much time you have :-)

As for using anything other than AD for security, yes, you'll lose more than you'll gain. I don't think its uncommon to create a group for each state you have users in, as a matter of fact I would expect for your AD to already cater for this physical structure of your organisation. My preference would be AD.

Your other option is to implement this in a separate DB and then access the information using a code call from your destination rule. If you do go this route, keep common pitfalls in mind like performance (you'd like it to be fast and possibly implement caching), maintainability (from a network admin perspective somebody would need to maintain this information via some user interface), maintainability (from a code perspective avoid dropping lots of code into your process as this would make future maintenance of your code *very* difficult, consider putting it behind a web service in order to keep your process 'light' and allow you to change logic in the service without impacting dependant processes).

A last option would be to build this physical structure of your company in SharePoint by adding a 'location' property to your users list in SharePoint and then accessing this information using custom code in a web service and then calling the web service from your destination rule or loading the property from a SharePoint list event into a datafield and then using the datafield as a destination rule...

Have fun!