cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Allow Vault actions to be executed immediately on the client instead of being queued as Job Processor jobs

Allow Vault actions to be executed immediately on the client instead of being queued as Job Processor jobs

Description:
Today Autodesk Vault primarily relies on the Job Processor infrastructure to execute publishing, synchronization, and automation workflows.

Historically this made sense to offload heavy processing from engineering workstations. However, modern client machines are now powerful enough to execute many of these jobs locally with minimal impact to the user.

 

For many companies, the Job Processor infrastructure introduces more complexity than value, including:

  • Job queue management
  • Failed jobs
  • Non-Tip Version issues
  • Lifecycle race conditions
  • Permission/configuration mismatches
  • Dedicated Job Processor maintenance

Suggested improvement:
Allow administrators to optionally execute jobs locally on the client that initiated the action instead of sending them to the Job Queue.

Examples:

  • Property Sync
  • PDF/DWF/STEP publish
  • Lightweight custom jobs

This could be configurable per job type or lifecycle transition.

 

Benefits:

  • Reduced dependency on Job Processor infrastructure
  • Fewer queue-related workflow failures
  • Faster workflow completion
  • Simpler Vault administration
  • Better reliability for small and medium Vault environments

This would not replace the Job Processor, but provide a hybrid approach where companies can choose the most suitable execution method for their workflows.

2 Comments
ihayesjr
Community Manager

@Ohm_IK 

Thank you for posting the Idea.

Property synchronization can be done locally on the machine. 

A custom Job should be developed as a locally executed job instead of sending it to the Job processor.

Ohm_IK
Participant

@ihayesjr 

Yes, I understand that Property Sync can already be executed locally by the user. However, users often do not have permission to modify files in the current lifecycle state, which is why the Job Processor uses a separate account with higher permissions.

 

My suggestion is therefore not simply to run the existing Job Processor locally, but to execute actions immediately on the initiating client, while still being controlled by Vault and respecting the existing permission model.

 

I also understand that third-party developers can create custom solutions for this today. My suggestion is that Autodesk provides this as a standard Vault feature to reduce common Job Queue and workflow issues.

Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea