Skip to main content
Nintex Community Menu Bar

We have a top level site with a list that contains information (site name, owner, URL, etc.) about subsites that have been created.  The scenario I’m trying to figure out is how to change a subsite’s URL and Title if a user changes the name of the subsite in the list at the top level.  I’m basically trying to use a workflow to accomplish changing the subsite URL and Title name.

 

I was able to do this on premise using the PowerShell action for Nintex Workflow that Aaron Labiosa created (NTX PowerShell Action - Stable Release).  But I’m striking out so far as to how to do this in O365 via Nintex Workflow.  Any ideas if this is even possible and if there are any approaches?

Eric, this should be possible, using the Call HTTP Web Service Action.  (Don't have time to go into outline it out), but you'll have to come up with a method of know what the current Site Title / URL are and the new Site Title / URL are to be at the top level list.  That way you can send a HTTP POST to the current site url web api to replace the Title and URL.

Will also need to make sure that your workflow has admin workflow permissions to do this.

I do this exact same mechanism (not with subsites but with document sets in a subsite) where the master data is controlled at a top level list.


Maybe Caroline Jung​ could help ? It seems to me she knows how to do this....


Exactly Thomas .

You can do this using SharePoint REST API (How to execute a SP2013 REST API request with Nintex Workflow).

Here's Microsoft's documentation regarding changing a site properties :

Webs REST API reference

To use this method you need the current subsite url.

You need to first get the request digest (I described how to do this in my blog) and then you can perform a POST web request with the following url :

the following headers :

  • Content type : application/json; odata=verbose
  • X-RequestDigest : the reference to the variable where you've stored the request digest that you've retrieved
  • X-HTTP-Method : MERGE

and the following body (choose content) :

  • { '__metadata': { 'type': 'SP.Web' }, 'Title': 'New subsite title','ServerRelativeUrl':'/sites/testsite/new-subsite-url' }

and you need to populate a username and password.

Note that there's a bug if you add references to workflow variables in the body of the web request. The workaround that I've found is to create a collection variable and add the following items Inside this collection (using several Add item to collection actions) :

  • { '__metadata': { 'type': 'SP.Web' }, 'Title': '
  • the reference to the workflow variable containing the new site title
  • ','ServerRelativeUrl':'
  • the reference to the workflow variable containing the new site url
  • ' }

Then you can use the Join Items in Collection action to get all this content in a workflow variable (and reference this workflow variable in the body/content part of the web request).

Don't hesitate if you need help.


Caroline, can you post a link to your blog? I searched around but was unable to find it. Thanks!


Here's the link to my blog post : How to execute a SP2013 REST API request with Nintex Workflow


Thank you Caroline.  Your guidance helped me figure this out.


Great ! I'm glad that I could help


Caroline Jung‌ I really appreciate you taking the time to provide a workaround for this wf variable bug in web-request actions, that saved me quite some time!!

Frank Fieldwhat's the best way to inquire about a timeline for a fix on this one? I'm working with a single variable in my web-request body, and this bug cost me 5 actions since the below isn't possible. That's quite painful when trying to development within the action count limitations of O365 (especially with more variables or header values like Caroline Jung's example).

Thanks!


not a problem – thanks for the info! I would definitely classify this one as a bug. :-P


I'm glad I could saved you some time


Hi Patrick,

The list of defects addressed in each release is listed on the release notes for each product. The links to the release notes is from the product install / download page.

Cheers Jon

Jon Hardy | Nintex®️ Workflow for Everyone®️ | Senior Product Manager | Jon.Hardy@nintex.com<mailto:Jon.Hardy@nintex.com> | T: +61 3 9972 2554 | M: +61 437 942 425


The real issue I found is when having curly brackets in a variable mixed in with other references as those also include curly brackets.  Somehow, the Nintex Workflow confuses the two and can't parse them.

A slightly simpler solution is to use tokens instead of the curly brackets and then use the Replace Substring in String action to substitute the curly brackets in place of the tokens.  So in my solution, I would use lcurl for left curly brackets and rcurl for right curly brackets.  The actions would be as follows:

  1. Set Workflow Variable:  Save the following text into a variable (e.g. body)  lcurl '__metadata': lcurl 'type': 'SP.Web' rcurl, 'Title': '‍{Current Item:Title}‍','ServerRelativeUrl':'‍{Current Item:Server Relative URL}‍' rcurl
  2. Replace Substring in String: Replace lcurl with {  in variable body
  3. Replace Substring in String: Replace rcurl with } in variable body

Then, you can use the body variable when needing to use the JSON string.

Regards,
-Haniel


I am trying to update site title using REST API.

I am getting bad request error or Forbidden error when i try to test the connection in web request action.
Same REST API url is giving me a result if i try through browser. Also I am able to access ASMX service through web request action for same account.

So, Just wanted to know is there any setting required to use REST service in web request action ?


In order for me to get this working, i only had to do a "Build string" action and store the result in a multiline variable ML_body

and after that, i could use ML_body in my web request action, but my headers are a bit different:


The account that you use to perform the request has to have the permission to change the site title.

Another reason that could cause the forbidden error is that the header "X-RequestDigest" hasn't been initialised in the web request or it's value is not correct.


Reply