Adding a look-up feature to a SharePoint workflow gives options to users. In this video, Gini Courter shows how to set up email list look-ups.
When we're creating a workflow and sending an email message, it's great if we know ahead of time who we should be addressing that message to. For example, in the first stage, we knew to send it back to the submitter. And we can grab that information very easily out of our sharepoint item. We know that Mark is the Finance VP. And we know that Carol is the h r v p. Those are known’s. The one that is unknown is the area v p review.
And I need to comment here that we are going to need to do a look up out of the department’s list in order to get that information. So, I want to show you how you retrieve and email address but you could be retrieving anything. What we're basically doing is creating a look up similar to a look up that you might create in Microsoft Excel. We're going to say, we have a value here. We're going to take our value, go to another list, look for a match to that value, and then retrieve another column. So I have a customer number. I'm going to a list of customers, find that same number, and pull back the customers address.
Pull back the customers tax rate. Whatever it is we want to pull back out of a different column. That's how this works. And of course it is a different column. If it was the same column we wouldn't need to do a look up. We already have the information in the matching column. So what we are going to do is email these users. And click to. And if we want to look up information, we're going to use workflow look up for user, and click, add. This is the same dialogue that we saw when we chose for example, the user who submitted the form.
Or we want to look for a particular piece of information within the current item. But we don't want to look in the current item. We have a list of departments that has the information in it that we need. And I want to show you that list in SharePoint real quickly. So here's the department's list. It has the following fields. Department, which is the name. The full name of the director. And in some cases that's not occupied because we're actually emailing, for example, in the case of marketing, we're sending this to in box, essentially, for the marketing department, not to the director of marketing.
But this is the directors email the title of that director if there is one an organizational area and whether or not this is an active address. So this list has a different purpose somebody else is maintaining this for us that's great. So when we're looking for a list that we can grab information from for a workflow, we want to know that that list exists, that no one will change it's structure without letting us know because for example, if someone decides to rename these fields it might give us an issue. Or if they decide to delete columns, we'll definitely have a problem.
So, a known list that somebody's maintaining. If we don't have one of those, we'll create that list ourselves in Sharepoint so that we can make sure that the information that we're relying on for our work flow is solid information that's well maintained. Let's slide back over to Sharepoint Designer now. And we want to do a look-up for a person or group in that department's list. So there are a whole bunch of data sources here. Everything that's in share point, the current list is just part of it, but we have the history and task list that are set up for the work flow, we have our documents library, or menta reports, but here's departments.
We're going to grab it right here. And it says, at the top, the field to retrieve data from. So, in the departments list we're fishing for an email. These are the fields in the departments list. And we want director email right there. And it will come back as a string. So that's cool. We're going to the departments list and grab in the director email. But how do we know which one we want to bring back? Well, that's what we're going to set here in the Find the List Item section. We're going to say that we have a department name.
Right here, so we want to search through that department column. And the value we're going to place on that is we're going to look in the current item for the department. So let me be clear of what we're doing here. We're saying that in the department's list, we want to return the director's email. And we want the row, or the record, where the field department in the departments data source matches the field department in the current item.
Looks good to me. Now, it's possible that there are multiple email addresses for the same department in the list, there is no in forced uniqueness on the department name, because of that when I say ok, share point designer is going to say the look up that you defined is not garunteed to return a single value, in other words some body might have added 5 email adresses for the sales department. And it says if more than one value comes back, I can only send an email to the first one, is that okay? And I'm going to say, yes it is.
I might want to actually enforce some uniqueness in that department's list, but it's not my list, so I have to have a conversation with whoever owns that list and make sure that that would be fine to do, and that they'd be happy to do it for me. So I'm going to say okay, and there is the director email for the departments. And we of course then would continue entering the information for this message. We have to at least enter a subject or we can't even save this form. So you have a have a new position request to review, you would put some more information in it, maybe the name of the position, you put an encoded absolute URL here.
Everything else, but all of those things we already know how to do. What we need to know how to do here is how to go grab a piece of information using a look up and that's what we've done. So, we're using email in exactly the same way as when we emailed the submitter and exactly the same way we would for example, if we hard coded an email in. I want to make one more point about this before we leave. There's a huge benefit to having this table, rather than typing in email addresses.
So even though we know Mark Lasee's email, and we could go click on these users and type his email in, down the road in the future if Mark is transitioned to a more important job outside of finanance or if Mark decideds that someone else in finance should be taking in this information. Maybe that the way that they're way doing this in the marketing and sales department where they're sending to a departmental inbox is better than all of them flooding into his inbox.
If the email changes and we've typed an email in, we've entered it or chosen a person then what we're going to need to do is come back in here and modify our work flow. So, we've entered Mark. And he's right there. But now I'd have to modify the workflow. So there's a benefit to me to look up ever single one of these. To actually have a table either an agreement that that department's table has the default contact that can be to use not just to reach the department but for work flows as well.
Or to set up my own list of departmental work flow IDs. Perhaps it would be good for all of my work flows... Maybe only for this particular workflow. My workflow will be much easier to maintain if I have the choice to simply go edit a list and change the email address, rather than needing to go into not just one, but perhaps multiple workflows to say. It's not actually Mark Lesee getting these anymore, it's finance at inside NOI, so something to consider, even when you know the email adress i think you are better off looking it up, because it makes your workflow far more maintainable.
- Automating workflows
- Documenting workflows with Sticky Notes, Excel, and Visio
- Driving workflow interactions with forms
- Using workflow actions
- Making choices and controlling flow with conditions
- Creating a simple form
- Using email notifications
- Pausing and stopping workflows with core actions
- Building a dictionary
- Creating a site workflow
- Deploying workflows
- Creating workflows visually