How to update a job after it has completed

Help Orchestrator
1

I’m creating an automation that looks for faulted jobs. I want it only to find a faulted job once - next time it runs it shouldn’t find that faulted job again.

But I don’t see anything in the Orchestrator API that would allow me to update a job such as adding a tag, or setting some other value.

Is my only option going to be to record a history of found jobs or some sort of “last run time” logic?

2

The only way I see you doing this is as you mentioned, creating a record history of job IDs you have already checked. Let me know if you think of something else.

3

Yeah I tried doing a PATCH against odata/Jobs and just get a 404 error.

Now it gets annoying because the Get Jobs activity doesn’t actually return any useful information about the jobs - it only gives you EndTime, EnvironmentName, PackageName, ProcessName, Source, StartTime, and State. No Id, no Key, etc.

Which means I’ll have to use Orchestrator HTTP Request and parse the JSON.

4

@postwick

last run time would be a good option..Yes you might not be able to add tags or references

cheers

5

Its really easy to parse the JSON output of an API now though, you can provide an example or the schema and it will generate a class for you with those properties so its not very much effort to read the output compared to the out of the box activity.

6

Hi @postwick

Yes, that’s expected. Jobs in Orchestrator are read-only once created, so you can’t tag them or update any fields via the API.

  • Store the Job Ids you’ve already processed (in a queue, database, or file) and skip them on the next run.
  • Use a “last successful check time” and only query faulted jobs created or ended after that timestamp.

Those are the supported patterns today, and they’re commonly used for this exact scenario.

7

It’s too bad there’s no way to update them. A feature where they can be marked as reviewed or something like that would be very useful, just like we can do for failed queue items.

8

Agreed, that would be very useful. Jobs being read-only does limit post-processing scenarios, especially for monitoring and review use cases. Today, UiPath treats jobs as immutable execution records, which is why features like “reviewed” or custom status flags don’t exist the way they do for queue items.

For now, the only reliable patterns are still external tracking (storing processed Job IDs) or time-based filtering. Many teams handle this by maintaining their own “job review” state outside Orchestrator. It’s a common ask, though, and worth raising as a feature request since the need is very real.

1 Like