Update space property in different space than trigger issue via Jira Automation

Pierre Ibrahim

So I have an interesting problem to solve. I have a sort of repository JIRA space with each work item correlating to a different JIRA space. Essentially our structure is we serve a lot of clients, each client has their own JIRA space, and the repository space has a work item for each client, with a field called JIRA Project Key (in the automation referenced as customfield_10395).

What I need to do is update a property on the appropriate client's JIRA space once any one of two fields change on the repository space's work item for that specific client.

I'm kinda able to do that, but it's a bit of a dumb workaround. I'm listening for any changes to those two fields on that repository space. If they change on edit, then I branch with a JQL that looks for the following: 

project = {{issue.customfield_10395}} and issuekey = {{issue.customfield_10395}}-1

You probably already see the issue here. If a client space has had the first work item deleted, this won't work. But I can't for the life of me figure out a way to do a "limit 1;" in JQL, or branch into a different space in a better way.

Below is my full automation:

Any help or guidance is greatly appreciated! 

Germán Morales

Hi @Pierre Ibrahim
 
That -1 trick is doing one very specific job in your rule: it forces the branch to land on a single issue that lives inside the client project, and that is the only reason your property action ends up scoped to the client space instead of the repository one. So the real fragility isn't JQL, it's that you're using an issue as a vehicle to switch project context, and the vehicle vanishes the moment that first issue is deleted. JQL has no LIMIT clause either, which is why you couldn't find a clean "limit 1", you were approximating it with the issue key.

The way out is to stop routing through an issue at all. A project property can be written directly by project key over REST, so you don't need a branch, a real issue, or the -1 assumption.

Replace the branch plus the "Set space property" action with a single Send web request action:

• Method: PUT
• URL: https://<your-site>.atlassian.net/rest/api/3/project/{{issue.customfield_10395}}/properties/jqlStringProperties
• Body: your value as valid, non-empty JSON (for example {"vp":"...","csg":"..."}), max 32768 characters
• Auth: basic auth header using email:apiToken, base64-encoded, same as any same-site REST call

Since you already resolve {{issue.customfield_10395}} inside your JQL, it resolves the same way in the URL, so the request targets the correct client project by key. Keep your two "Create lookup table" steps before the web request and reference {{VP}} and {{csg}} when you build the JSON body. That part of your rule doesn't need to change.

Why this is robust: there's no dependency on any issue existing in the client project, so it works even if every work item there was deleted, and it runs exactly once per trigger instead of once per matched issue. Endpoint reference: Project properties (Jira Cloud REST API v3), and the action itself: Jira automation actions.

Two things to watch. The account behind the token (or the rule actor, if you authenticate differently) needs Administer Projects on each client project, otherwise the PUT comes back 403. And when you later read the value in a rule on the client space, it's addressed as {{project.properties."jqlStringProperties"}}.

If you paste the exact shape of the two fields you're storing, I'll help you assemble the JSON body so it stays valid when one of them is empty.