Inserting the Edit Item URL in Workflow Notifications

[cassymfreeman]

Problem

Often I have workflows with approval (assign flexi task) actions in that usually run the same generic course:

• On approve, change status, send notification
• On reject, change status, send notification asking for updates

Now I love the out of the box “Common” properties that can be utilised in workflow such as Approver Comments, Current Date etc. but what I think is missing from here is a link to the item in edit mode (if someone knows how to solve this problem more easily please let me know).

Often in the reject email the text will say something along the lines of:

Your request has been rejected for the following reasons:

{Common:LastApproverComments}

Please address the issues and resubmit using the link below:

Edit item URL

Solution

I was pointed to this awesome article by a colleague that describes the different page types available in SharePoint – this might be old news to many but having just discovered it I am now obsessed

https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.client.pagetype.aspx

So using this and the built in common properties in Nintex Workflow I am able to set a variable value at the beginning of my workflows to build the URL for the current item to open in the edit page:

I can now use this variable vTextEditItemUrl in my rejection emails to allow the user to open the item directly in edit mode and resubmit without any additional clicks in the ribbon.  Also because we are using the common variables we can be certain that whichever environment this is deployed to it will build the URL correctly as there is no hard coding to change before publishing.

This may be of no use to anyone but me, but anything I find I like to keep safe here in the Nintex Community for the next time I need it.  If it helps anyone else then that is a bonus

Enjoy!

[greenawayr]

An alternative way to build the URL is like so:

domain/sites/sitecollection/lists/listname/editform.aspx?ID=1234

[davisn]

How do you do this with different content types however, if you want to open a certain form? Adding &Cotentype= @ the end does not always work for me...

[jesse_mchargue]

This is how I build the links as well. It seems the most straightforward when explaining it to other users.

I keep it simple and have them use:

newform.aspx - New Items

dispform.aspx?ID= - open form in display mode.

editform.aspx?ID= - open form in edit mode.

Great post Cassy Freeman​! I always find it interesting how others view and tackle the same "issues" but using different tools and approaches

[davisn]

Jesse,

That works in some situations, but my situation is one where there are different roles in the process, so i have 1 form for each of those roles. The forms are sepearte by content type. So have 3 different views, each with a different hyperlink to the form that is relavant to that role. So the hyperlink has the content type id in it. The problem is, this seems to mess up from time to time...

[jesse_mchargue]

nick davis​ -

I could see that happening. Are you using Nintex Forms? Have you tried hiding sections based on user group membership?

I use this in a few forms where approvers or managment are given "extra" fields based on what user groups they are in. This allows me to hide/show sections all in the same form and the end user doesn't see or feel any differences.

Here is an example of what I did with out project managers and their managers:

Project Manager View:

Portfolio Management View (the users that actually approve if a project is a go or no go):

All I did is hide a section of the form like so:

Again, all this does is hide or show a section based on group membership. This requires that the user roles (in your case) are reflected properly in SharePoint User groups.

[greenawayr]

nick davis use the ContentTypeID query string. You can find your Content Type ID from the Content Type settings page in the URL.

[ms]

I use this method too:

{Common:WebUrl}/Lists/{Common:ListName}/DispForm.aspx?ID={ItemProperty:ID}

{Common:WebUrl}/Lists/{Common:ListName}/EditForm.aspx?ID={ItemProperty:ID}

However I've hit a wall when I rename the list where the list display name changes but the list URL does not.

For example, I create a list called "MyList" then rename the list to "My List". The URL for the list is "MyList" but the display name for the list is "My List".

Now when I use the Nintex Common:ListName property in the URL it uses the lists display name instead of the system name, e.g.:

{Common:ListName} equals "My List" not "MyList" therefore {Common:WebUrl}/Lists/{Common:ListName}/ points to an incorrect URL.

Mitch

EDIT: The solution is to use the Inline Function Replace to remove the space from the URL:

{Common:WebUrl}/Lists/fn-Replace({Common:ListName}, ,)

[#9]

Thanks. It is very straight forward and make easy to add this URL in email notification 

[nps9]

This is really helpful! Being able to send somebody directly to the edit form is great.

[akrasheninnikov]

Make sure you don't send links to Edit forms to users who only have Read access, because they'll get Access Denied.

[loeloe]

Good day,

I created a Variable and added the String specified by Cassie but I am not very clever with this at all. The link does not work. Can you provide me with more info please. I must be doing something wrong.

many thanks

[nps9]

The easier thing to do is paste this exact line:

{Common:WebUrl}/Lists/{Common:ListName}/EditForm.aspx?ID={ItemProperty:ID}

It will set the correct values for you.

[nps9]

As mentioned above, the user must have edit rights for the link to work. Also if you re-name the list that can cause a problem.

[loeloe]

Thanks John busy Publishing the Workflow and the name of the list won't change.

[loeloe]

I found my problem, the SharePoint List should not have any spaces in the NAME.

Thanks again for everybody's help.

Have a super day!

[cmikhaiel]

We did it with a one hacky regex to the "ContextItemURL". 

[rossk]

@cmikhaiel That isn't hacky at all! (the fact that we have to do this at all is a little hacky) Yours is the best solution here in my opinion as it's fully portable and you don't have to worry about spaces, etc... Thanks!

[standiamond]

Thanks, that is much better than just constructing the string in the notification text.  Doing the latter required me to edit the HTML to clear out some garbage text, and that of course leaves a maintenance problem for the future.  Thanks again, Stan.