sharepoinTony

@info – The practical side of SharePoint

Archive for the ‘Workflow’ Category

USPJ does a great job

Posted by sharepoinTony on September 26, 2010

I finally got to read through the latest Understanding SharePoint Journal and I have to say I was impressed.  

The journal is clear and concise, it is very informative, and it is very easy to read.  The level of detail is great for anyone learning about SharePoint and provides sufficient information to allow you to build something of value by the time you finish reading.  In fact, the examples allow you to follow along and build something while you are reading. 

The format of these journals focus on one topic at a time, allowing you to get more depth in the topic and learning more without feeling like you sat through a lecture.  The coverage of the topic is excellent and fits the audience well.  I highly recommending the Understanding SharePoint Journal to anyone trying to learn SharePoint or learn more about SharePoint.   I certainly learned more about SharePoint 2010 Workflows than I expected after reading this issue.

Kudo’s to Bjorn and the USPJ team.

Advertisements

Posted in Commentary, SharePoint Tools, Workflow | Tagged: , | Leave a Comment »

Lean Thinking for SharePoint

Posted by sharepoinTony on August 27, 2010

I have to start this with a tidbit of history.  You see, I actually did something before I began working with SharePoint…surprising as that may sound.  For several years prior to SharePoint I had a really long job title, but the gist of what I did was implement Lean practices in a corporate setting.  My focus was on the “office” which meant any business function that wasn’t on the factory floor.

So what is Lean?

There are books that go into depth on the subject, and Wikipedia provides some definitions, but my personal short description is this: Lean is a way of thinking and working that incorporates continuous improvement, process improvement, and efficient practices.  It is all about eliminating waste in your business.

Lean is what lead me to SharePoint.  When I first saw SharePoint and learned the things it could do, I jumped into it.  SharePoint was the tool I was looking for to help implement new processes, to help business staff embrace Lean concepts, and to help the company benefit from the Lean effort.  I got excited about SharePoint and haven’t looked back.

One of the cool things about SharePoint is the concept of distributing the work and enabling people to create what they need in a site.  Eliminate the bottleneck.  That is a Lean thought, it is a Lean way of doing things.  Lean is about empowering your staff to do the things that they need to do to get their job done.  And you want them to succeed, to excel, and to do it all without WASTE.

How many times have you experienced the waste most companies tolerate?  Wasted time, wasted spending, wasted energy.  Lean is about eliminating those wastes.  By capturing the time, energy, and money previously lost in that waste you can redirect all of that into improvements that benefit the company.  You can take a week-long process and make it into a few hour process.  When your company shortens process times it becomes more competitive, more cost-effective and usually more profitable.

What is Lean Thinking for SharePoint?

Although there are lots of benefits to studying Lean, I think that by simply using a few Lean concepts your SharePoint activities can make significant improvements that benefit your company.  “SharePoint people” can easily pick up these concepts and incorporate them into their work.  A perfect example is the implementation of a new workflow.

We typically attack a workflow request by asking about the process and capturing key steps we know we will need to create a SharePoint workflow.  But what if we take the opportunity to ask questions?  Why are those steps needed?  Who really needs to be involved?  What is that information used for and by whom?  But don’t stop there…you have to follow-up by tracking that information flow.  What does that person actually do with the information?  Is it even used?

That is the tough part.  People always say they know the process or they know the requirements.  Never believe them.  I cannot tell you how many times I followed a process, tracked the information flow across multiple branches and up the chain of command only to find out that the end result was never used.  Everyone in the organization had accepted the process, enforced the perceived “need” and just “knew” that we had that do it that way.  It often turns out that someone in some department said they needed the information and that filtered its way into the process over time.  It sounded valuable, so management made it a requirement.  Everyone got used to the “requirement” and it became part of the culture of the business.  Years ago that probably was needed information.  The business had to change to stay competitive, but  business processes lag behind and are not updated.

Taking the time to truly find out what is needed and why it is needed allows you to create a process, in a SharePoint workflow, that reduces work and eliminates waste.   By taking the time to do this, even if you don’t find any waste you will gain a solid understanding of the process and have documented the process which is of value to the company.  Having to change a workflow to correct the process isn’t fun and is a form of waste.  Just do it right the first time and you will save time and money.

Resources you can use to learn more about Lean:

Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated
by James P. Womack, Daniel T. Jones
Easier, Simpler, Faster: Systems Strategy for Lean IT
by Jean Cunningham, Duane Jones
Office Kaizen: Transforming Office Operations into a Strategic Competitive Advantage
by William Lareau
The Lean Office: Collected Practices and Cases (Insights on Implementation)
by Productivity Press Development Team
Lean Administration: Case Studies in Leadership and Improvement (Enterprise Excellence)
by AME – Association for Manufacturing Excellence

Posted in Best Practice, Lean, Workflow | Tagged: , | Leave a Comment »

“New Item Added” Alert not working

Posted by sharepoinTony on July 23, 2010

I hope there is a happy ending to this story, I will update it when I find out. [Updated 7/26/2010]

Here is the situation

MOSS 2007, Alerts set on a Survey list.  Users complain that although they have set up Alert Me to tell them when a New Item is Added they are not getting the email alert.

I setup my own Alerts to test behavior, here is the run down:

  • Creating an Alert produces the “successfully create an alert” email message
  • Changing an item produces the item “has been changed” alert email message
  • Deleting an item produces the item “has been deleted” alert email message
  • Creating a new item DOES NOT produce the “New item added” alert email
  • Alerts on other lists in same site behave normally (all Alerts work as expected)

Some of the things I have done to troubleshoot/resolve this behavior:

  • Restarted the Timer service
  • Verified the Timer service was running
  • Checked the Timer Status in Central Administration – everything Successful and 100%
  • Checked the properties:

STSADM -o getproperty -url http://YourSiteURL -pn alerts-enabled
STSADM -o getproperty -url http://YourSiteURL–pn job-immediate-alerts

  • Re-registered the Alert Templates

stsadm -o updatealerttemplates -url http://YourSiteURL -f “c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\alerttemplates.xml” -LCID 1033

Behavior after Re-registering the Alert Templates – same as before re-registering, ugh.

Decided to test more alerts on other sites, ah-ha!

  • Other sites in the collection with lists using Alerts behave as expected – “New Item Added” Alert works!

So what do we have?  Behavior is localized to this survey and only impacts New Item Alerts.  Wait, that sentence made me verify…other survey’s behave the same way!  So the problem is not with that “list” it is a problem for all survey’s.

Workaround’s

One workaround that was plausible was to create a workflow to send notifications when new items are created.  This seemed plausible only because in this situation, the users had already requested assistance creating an approval workflow for this survey.   I decided to do a quick test by setting up an approval workflow.  The workflow fails to start.

Following this trail actually helped me get to the bottom of all of this.  I finally came across this Microsoft support article explains how “starting a workflow from a survey response is not supported in Windows SharePoint Services 3.0” – and the article  “Applies To” MOSS 2007 as well.

That lead me to some blogs saying that Microsoft does not support “New item added” Alerts on SharePoint Survey’s in WSS 3.0 or MOSS 2007.   These blog postings were older, so I wanted to find either ‘new’ postings or something that I could consider more reliable.  After searching further I found a hotfix mentioning this behavior – KB983307 Description of the SharePoint Server 2007 hotfix package (sts-x-none.msp): June 29, 2010.

Resolution

What have we learned?

  1. The Alert behavior is a known problem in WSS 3.0 and MOSS 2007; there is a fix, but you will want to review that material and make a decision regarding installing it in your environment or not.
  2. Workflows are not supported for SharePoint Survey’s for WSS 3.0 and MOSS 2007, so keep that in mind to avoid the obvious issues and let your users know that they shouldn’t create Survey’s if they want to eventually attach a workflow.

Epilog (of sorts)

Using Alerts to notify people of Changes to items in Survey’s does work, however you should evaluate what you are trying to accomplish and choose the best tool.  Survey’s are quick and easy to build, so make use of this nice tool built-in to SharePoint when you need it…just be aware of the potential pros and cons associated with using them.

Posted in Alerts, Lists, SharePoint 2007, Survey, Workflow | Tagged: , , , | Leave a Comment »

Service Requests and Sensitivity

Posted by sharepoinTony on January 25, 2010

I recently implemented a customized version of the Microsoft Help Desk template for SharePoint 2007.  Quickly after launching I adjusted things based on feedback and input that never came prior to the launch.

Background

The service request system, implemented via the help desk template, by default requires that all employees have access to submit requests.  The open-nature of SharePoint (and most IT departments) also dictates that users be able to see the pending service requests.  This visibility is normally thought of as a good thing for IT and helps promote self-service internally.  One of the customizations that I put in place was a notification workflow that sent email to the help desk staff telling them of newly submitted requests.  This workflow also automatically responded to the customer via email providing confirmation that their submission was successful.  The email provides a link back to the service request list so the customer could see all of the pending requests, including their own.

The Request

One significant post-launch request came from Human Resources.  They occassionally make requests that are sensitive in nature, such as terminations.  HR felt that those requests should not be visible to all employees.  This posed a problem for the service request list.  There is no doubt that it is a valid request, and the desire to keep most requests visible to users hadn’t changed, so I now had an exception to deal with.
Options considered were limited for various reasons.  One option would be to simply make a duplicate request list for sensitive HR requests.  But that meant managing two lists for the help desk, tracking two lists worth of requests for IT management, and created a possibility that a request might sit un-noticed.
Another option was to avoid using the service request list for all sensitive requests.  HR could send an email request as they had done historically in this small company.  Everyone was already “comfortable” with that process, however no improvements would easily fit into the old email process.  Reverting back to an old process just didn’t sound good unless there wasn’t a better solution.

The Solution

The solution concept chosen was to install a CodePlex feature that would allow a workflow to change the permissions on specific requests.
The concept was that sensitive requests could easily be identified since HR knew at the time of submission whether or not the request was sensitive, and could simply ‘mark’ the request as sensitive.  The workflow could check the column used for this purpose and based on its value could change permissions on that specific item.  We could limit the visibility to the appropriate staff without significantly changing the existing service request system.

The “Useful SPD Workflow Activities” feature from CodePlex was installed on a test server and the concept was examined closer.  After successful examination and testing it was decided that this would provide a very acceptable solution to the situation, and a quick response to the request from HR.
I created a new workflow to manage these permissions changes for two reasons.  First, I like keeping workflows as simple as possible.  Second, I wanted to be able to provide the flexibility to execute this behavior without sending emails that may be confusing which might come from adding these steps into the existing notification workflow.
The new workflow is very simple.  I check the designated column in the service request list and if it indicates that the item is sensitive then I remove a SharePoint Group’s permissions to the list item. I use several SP Groups to provide access, one contains all users, one contains appropriate HR staff, and one contains help desk staff.  When I remove all permissions from the group containing all users then only the members of the HR and Help Desk groups can see the item in the service request list.  There is no impact to other users or other requests.

Because the workflow can be started manually, we have the flexibility to “hide” any request that comes in by simply modifying the designated field and initiating the workflow.  This means that if HR forgets to “flag” a request, or if any other request is deemed sensitive we can quickly and easily “fix” it without having a workflow running all the time to monitor changes to requests.  Everyone is happy with this solution and it took longer to write this blog post than it did to implement in production.
Footnote: This CodePlex feature was installed and implemented on a 64-bit Windows Server 2008 system running MOSS 2007.

Posted in Lists, Permissions, SharePoint Tools, Workflow | Tagged: , | Comments Off on Service Requests and Sensitivity

Workflow tidbits

Posted by sharepoinTony on September 12, 2009

I meant to post these awhile back, and I may add to this post over time as I collect or recall  the handy little learning’s that I have stored up in the nooks and cranny’s of my brain.

Starting a Workflow Manually

In order to manually start a workflow created in SPD (SharePoint Designer) the user must have Manage Lists permissions on that list.   The workflow can start “on new” or “on change” with just standard contribute permissions…but, starting it manually is considered “managing” the list.

EMail link to list item in a Workflow

If you want to go directly to the details of a particular list item (basically reconstructing the URL used by SharePoint) use the SPD workflow properties below to build your link:

“<a href=” & workflowProperties.SiteUrl & workflowProperties.ListUrl & “/DispForm.aspx?ID=” & workflowProperties.ItemId&”>”

Posted in SharePoint 2007, Workflow | Tagged: , | Comments Off on Workflow tidbits

Case Study: MTV using SharePoint

Posted by sharepoinTony on July 7, 2009

Found this, thought it was interesting and wanted to share:

Case Study: MTV Networks International (MTV) (From TechTarget)
MTV’s Information Services and Technology (IS&T) department wanted to reduce the time that was wasted on manual processes. It chose Microsoft Office SharePoint Server 2007. IS&T used the out-of-the-box workflow capabilities of SharePoint Server 2007 to improve departmental efficiencies by automating a paper-based process for new employees.

Posted in Commentary, SharePoint 2007, SharePoint Links, Workflow | Tagged: , , , | 1 Comment »

Calendar Reminder (Part 2)

Posted by sharepoinTony on April 15, 2009

In Poor Folks Calendar Reminder (Part 1) the problem, the request, the plan of attack, and the first step in building a reminder behavior in a SharePoint 2007 calendar was covered.  This post is the final installment on this topic.

Building Steps – People

Since each calendar due date/event could have a different set of people to notify, I decided that my initial implementation of this would be simple.  I kept it simple by using a plain multi-line text field in the calendar list to capture the email addresses of the desired recipients.  So in addition to the List Fields mentioned last time, I also created the following column:

ReminderEmail – Multiple lines of text, not required, 6 lines for editing, Plain text

In the future I may make a modification to improve this feature of the reminder depending on how the email is really used.  For your reviewing pleasure, here is what my columns look like:

Reminder Columns added to Calendar List

Reminder Columns added to Calendar List

Building Steps – Workflow 1

My workflow has four steps, each described below.   To build this workflow:

  1. Launch SPD (SharePoint Designer)
  2. Open your site
  3. Select File, New, Workflow
  4. In the Workflow Designer window, Name your workflow (default is Workflow 1)
  5. Select the Calendar list that has the “reminder” columns added
  6. Check the Automatically start this workflow when a new item is created check-box
  7. Keep the check in the Allow this workflow to be manually started from an item check-box
  8. Click Next

Before we start creating Step 1, I want to add some Initiation Parameters.  I will explain why, and it will be more apparent why later, so for now just click on the Initiation… button, we will add two parameters:

  1. In the Workflow Initiation Parameters window click the Add… button
  2. Field Name: ResetDate
  3. Information Type:  Choice (menu to choose from)
  4. Click Next
  5. Enter the Choices: “No” and “Yes”
  6. Default value: No
  7. Display as: Radio buttons
  8. Click Finish
  9. Click Add…
  10. Field Name: TempDateTime (I chose this name to avoid any possible conflict with other variables, functions, reserved words, etc)
  11. Information Type: Date and Time
  12. Next
  13. Select the Use date and time item creation as default or Blank default value radio button
  14. Display format: Date and time
  15. Click Finish
  16. Click OK to save the Initiation Parameters and close the Workflow Initiation Parameters window
Workflow Initiation Parameters

Workflow Initiation Parameters

Step 1 – Check Reminder, Set Variables

Step 1 will have 4 Conditional Branch’s :

Conditions: select Compare Calendar field, then select the Reminder field in the Current item and set it equal to “No”

select Compare any data source, then select Workflow Data and the Field Initiation:ResetDate, set it equal to “No”

Actions:

select Set Field in Current Item then select the ReminderStatus field to “No Reminder Set”

select Log to History List, enter “ReminderStatus Set to No Reminder Set”

select Stop Workflow, enter “No Reminder Requested”

This first condition checks to see if the user chose to send a reminder for the event/calendar item.  If they did not (No value in the Reminder column) then we want to note that in the ReminderStatus column, log it in the workflow history and Stop the workflow.  The default for our Initiation Parameter ResetDate is No, so our workflow would stop here if the workflow automatically started on a newly created item and the user selected not to send a reminder.

For the remaining Conditions, I will assume you can select the correct components to insert and simply show you the end result.

Workflow Step 1

Workflow Step 1

Conditions: Else if Reminder equals Yes

and Initiation: ResetDate equals Yes

Actions:

Log “Reminder Requested” to the workflow history list

then set ReminderStatus to Waiting
then set ReminderDate to Initiation:TempDateTime
then Log “Set Status to Waiting, Set ReminderDate” to the workflow history list

Conditions: Else if Reminder equals No

and Initiation: ResetDate equals Yes

Actions:

Log “Reminder Requested Manually” to the workflow history list

then set ReminderStatus to Waiting
then set ReminderDate to Initiation:TempDateTime
then Log “Set Status to Waiting, Manual ReminderDate” to the workflow history list

Conditions: Else if Reminder equals Yes

and Initiation: ResetDate equals No

Actions:

Log “Reminder Requested” to the workflow history list

then set ReminderStatus to Waiting
then Log “Set Status to Waiting,Using Item ReminderDate” to the workflow history list

Step 2 – Pause Using Days

This step handles the user option of selecting the number of days prior to the event that the reminder should be sent.  This step contains the same number of Conditional Branch’s as you determine.  Mine contains 6 because I provide 6 options to the user (0,1,2,3,4,7) however I will only present a few here, the same concept applies to each that you repeat.

Conditions: If ReminderDays equals 0

Actions: Log ReminderDays is 0 to the workflow history list

If the user hasn’t selected a number of days, and the default is 0 then we want to make note of it, but continue on.

Conditions: Else if ReminderDays equals 1

Actions:

Add -1 days to Calendar:Start Time (Output to Variable:date1)

then Log “1 Day Reminder – Pausing Until:” to the workflow history list

then Log Variable:date1 to the workflow history list

then Pause until Variable:date1

Conditions: Else if ReminderDays equals 2

Actions:

Add -2 days to Calendar:Start Time (Output to Variable:date2)

then Log “2 Day Reminder – Pausing Until:” to the workflow history list

then Log Variable:date2 to the workflow history list

then Pause until Variable:date2

For each of your options simply subtract the number of days found in the ReminderDays column of the current item.

Workflow Step 2

Workflow Step 2

Step 3 – Pause Using Date

This step handles the user option of sending the reminder on a specific date.  It only contains one Conditional Branch:

Conditions: If ReminderDays equals 0

and ReminderDate is greater than or equal to Today

Actions:

Log Pausing Until Date: to the workflow history list

then Log Calendar:ReminderDate to the workflow history list

then Pause until Calendar:ReminderDate

Workflow Step 3

Workflow Step 3

Step 4 – Send Reminder

The final step in our workflow simply checks to see that we are actually supposed to send a reminder, so one Conditional Branch handles it all:

Conditions: If Reminder equals Yes

Actions:

then Log “Sending Reminder to:” to the workflow history list

then Log Calendar:ReminderEmail to the workflow history list

then Set Variable:EmailAddresses to Calendar:ReminderEmail (this allows us to use the variable in the actual email To field)

then Email Variable:EmailAddresses

then Log “Email Sent – Ending Normally” to the workflow history list

Final Discussion

So what does our new workflow do?  We collect the options the user selected when creating the Calendar item in our new columns, and use that to determine how to Pause the workflow until the correct amount of time has passed.  Then we simply pause for that time and send the email with the desired reminder text.

Why we have the Initiation Parameters should be more apparent to you now.  If the user wants to run this workflow manually because they didn’t set a reminder originally or if they want to send another reminder our workflow would run and stop without sending the reminder email without these parameters.  By asking for the two parameters when running manually we give the user the option to kick off the workflow and adjust the reminder date or add a reminder date for that instance of the workflow.   You can see how I use this in Step 1 to update the ReminderDate column and use that date to pause and send the email reminder.

Posted in Calendar, Designer, Reminder, SharePoint 2007, Workflow | Tagged: , , | 96 Comments »

Poor Folk’s Calendar Reminder (part 1)

Posted by sharepoinTony on April 10, 2009

I received a request from a small department that has a (MOSS 2007) site on one of our SharePoint portals.  The group is an accounting group who, like most accounting groups, has a calendar full of due dates for various accounting activity.  There are a handful of those due dates which are for accountants in other locations to submit something back to this accounting group.   The accounting group establishes these due dates and enters them on this one specific SharePoint calendar.

The Problem

Although everyone involved in this process has access to the calendar, most of the remote accountants do not regulary visit the calendar.  They call and ask when something is due.  Often they don’t call, someone in the local accounting group has to call them looking for something that was due today or yesterday.

The Request

Allow the user creating the calendar item to mark it for reminders and define who should receive the reminders for each event.

Discussion

This is a sore spot for me.  Microsoft obviously knows how to enable reminders on calendars, it has been around in Outlook for a very long time.   They really should have enabled reminders in SharePoint calendars without having to fully integrate with Outlook…and in my opinion, should have enabled the features requested above as part of the base SharePoint calendar feature set.

Additionally, I know there are several very good third-party tools to accomplish this.  I also know there are numerous methods to accomplish this with some custom coding.  However, as the title of this indicates, this is one possible method which I was able to implement at no cost and doesn’t require me to tap our understaffed, overworked and highly paid developers.

I am happy to hear any and all comments, improvements, or arguments about my implementation, I believe in continuous improvement.

The Poor Folk’s Solution

After reviewing several good blogs related to this topic of setting up reminders using a workflow, I came up with the following for my solution.  Relatively easy to implement, easy to use, and flexible enough to allow some notification options for the users.  Primary requirement was to meet the basic needs of the users.

Plan of attack – Overview of solution

My workflow is actually very simple from a flow-chart point of view.  I have 4 steps, the first checks to see if a ‘reminder’ flag is set, if it isn’t the workflow stops.  The second step checks selections made by the creator of the event, sets variables, and pauses for a pre-determined amount of time – if the user chose to remind a certain number of days prior to the event.  The third step checks for a specific date reminder and pauses until that date – if that is what the user chose.  The fourth step verifies the flag after the pause and sends the email notification.

My concept evolved during the implementation of this solution.  At first I made the user select a specific date that they wanted the reminder email sent out.  This wasn’t very flexible and required the user to calculate out the dates themselves.  After talking with the primary users, I learned that they had a short list of possiblities that they expected.  The would want to set reminders 1, 2, 3, 4 or 7 days in advance of the event.  Why not just let them chose one of these options.  Since I already set up the “reminder date” column in the list from my starting concept, I decided to keep it and allow additional flexibility.  The user could then either choose a specific date for the reminder or select one of the predetermined options.

Building Steps – List Fields

I added the following fields to the Calendar list:

Reminder – This is a Yes/No column (actually setup as a Choice column with Yes/No options)

ReminderDate – This is a Date and Time column

ReminderDays – This is a Choice column, with choices of “0,1,2,3,4,7” and a default of 0

I also added ReminderStatus as a Single line of text column so that I could update it from within the workflow to provide some status information right in the calendar list (I create a standard view displaying these fields rather than the standard calendar view).  You may not want this, so consider it an optional field.

These fields need to be created first so that they are available to SharePoint Designer when creating the workflow.

Next Time:
Building Steps – People

Building Steps – Workflow 1

Calendar Reminder (Part 2)

Posted in Calendar, Designer, Lists, Reminder, SharePoint 2007, Workflow | Tagged: , , , | 3 Comments »

Using alternate list data in a SPD Workflow.

Posted by sharepoinTony on March 27, 2009

Background:  MOSS 2007, SharePoint Designer 2007 used to create the workflow.

I have a user request workflow which is initiated when a new item is created in a user request list.  The user is required to select a ‘location’ when submitting the form (this form is used by many different locations in the USA).  Depending on the type of request an approval may be needed and I send an email to a designated approver based on the location that was selected by the user.   The user doesn’t know who the approver is and the support desk staff may or may not know either.  I currently am using hard-coded email addresses for the approvers in my workflow.  I ‘set’ a column with the email address once it is determined in the workflow and in later steps use that field in the email message.

What I would like to do is use another list to allow us to maintain the approvers, their appropriate email address, and the location where they are allowed to approve requests.

Here is how I did it:

  1. Edit my workflow in SharePoint Designer (SPD)
  2. Navigate to the appropriate step and conditional branch.
  3. Modify the “Set” field line,  selecting my  ‘other list’ as Source in the “Lookup Details” section of the Define Workflow Lookup window (note that this window opens when you select another list in the Source drop-down).
  4. Select the field in that source that I want used in the user request list for the Field selection of the Lookup Details section.
  5. Under “Find the List Item” section, I used the other list Location column in the Field selection.
  6. I then used the current list Location in the Value selection
  7. Click OK to close the Define Workflow Lookup window.
  8. Click YES to the warning (if it displays) that says “The lookup that you defined is not guaranteed to return a single value.” etc.. “Do you want to continue?”
  9. Finish your workflow to save and close the Workflow Designer window.
  10. Test it out – The appropriate approver is pulled from my “approval maintenance” list and placed into the current list item in my user request list!

This took me a little effort to figure out, it isn’t clearly documented and I couldn’t find it in the SPD help.  Maybe someone else will be able to use this, and shortcut their search effort to figure out how to do this kind of lookup in a workflow.

Posted in Designer, SharePoint Links, Workflow | Tagged: , , | 2 Comments »