I have a list called "Requests". This list has a text field called REQ-ID that is an "ID" field that corresponds exactly with the built in ID field (a workflow on item created populates the REQ-ID field with "REQ-[%CurrentItem:ID%]").

Through whatever business process, these requests get approved.

Now the users want a way to create a new "request" that is really an update to a previously approved request, and the approvers want to know the REQ-ID of the previously approved request.

Easy - add a lookup field (named Previously Approved Request) that refers back to the same "Requests" list it's on, and have it show the REQ-ID field.

Done. Shows up on forms, when users are creating new requests, if it's an update of an old one they can choose the REQ-ID of the old one to link it back. No issues there.

However, now I want to add a little message to the email that goes out alerting the approvers that this new request they are getting notified about happens to be an update to a previously approved request, and include the REQ-ID from the looked up item in the Previously Approved Request field. But I can't because the Previously Approved Request field does not show up when I try to do a workflow lookup to [%CurrentItem:<FieldName>%]. The Previously Approved Request field does not show up in the list of available fields to get from the current item.

This is from a list workflow (item created) on the "Request" list, the same list that the column is on and that the column is a lookup to.

I have gone into the list itself through the SPD interface, and can confirm that SPD sees the column on the list (with it's correct settings), and sees the column in the default Item list content type (in the correct position, etc.). I even tried clearing my SPD cache to force it to reload everything about the site. Same thing, still sees it on the list, but it just isn't there when I want to access it from a workflow.

Why? Where did it go?

1 Answer 1


It's by design, You CAN'T use a lookup column that read from the same list in SharePoint Designer Workflow!

In your case, I would suggest doing the following:

  • Creating a new list for Previously Approved Request List.
  • In the Requests list, create a lookup field Previously Approved Request that refers to the newly created list instead of referring back to the same list.
  • In your workflow, add a new action to add a new item to the newly created list when an item approved.
  • Now, The lookup field Previously Approved Requestthat refers to another list should be shown in your SharePoint Designer Workflow.
  • That's an interesting suggestion, but it starts to get into the messiness of splitting up data and making something a bit more complex than it needs to be. I'll consider it though. But I may just tell the users that they won't get the REQ-ID of a previous request in the email notifications. There's also a bool field that marks the item as being an update to a previous request, which I can access in the workflow, so I can let people know the new request is an update, even if I can't give them the specific ID. They'll just have to go to the new request to click through to the old one. Commented Jan 30, 2021 at 20:37
  • 1
    Actually I just thought of a better solution. I am using 2013 workflows, so if the request is marked as an update through the yes/no field, I can just make a REST call to get the value of the lookup field. Done. (And, since the REQ-ID field is 1-to-1 with the built in ID field, I don't even need to do any fancy expanding, I can just query for LookupFieldNameId and rebuild the REQ-ID string in the workflow. Easy peasy.) Commented Jan 30, 2021 at 20:53
  • Yes, your suggestion is awesome, In my answer, I just have tried to highlight the limitation and introduce a workaround based on what you have mentioned in your question, and for sure, you have the full scenario and know more about the current requirements. so that you can effectively choose the proper solution ;) Good Luck ♥ Commented Jan 30, 2021 at 21:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.