{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":3746,"path":"build-workflows/legacy-workflow/c_WorkflowEngineOperationOrder.md","title":"Workflow engine operation order","bundle":null,"doc_type":null,"release":"australia","body":"\n# Workflow engine operation order\n\nThe workflow engine runs in a predefined order relative to business rules and database operations. It caches commonly-used published workflows to improve performance.\n\nThe **Run after bus. rules run** workflow property defines if a workflow is **Default** or **Deferred**.\n\nThe diagram below shows the workflow engine order of operations and when Default and Deferred flows are executed. For a more general overview of engine operation order, see [Execution order of scripts and engines](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/api-reference/scripts/r_ExecutionOrderScriptsAndEngines.md).\n\n\\[Omitted image \"WFEngineOrderDiagram.png\"\\] Alt text:\n\n## Workflow caching\n\nThe workflow engine caches commonly-used published workflows to improve performance.\n\nCaching significantly reduces the number of database queries per workflow. By default, the engine caches up to 300 unique workflow versions. Caching very large workflows may reduce this number as the cache size cannot exceed the Java Virtual Machine \\(JVM\\) heap size.\n\nTo change the maximum number of cached workflow versions, navigate to **Workflow** > **Administration** > **Properties** and modify the value of the **The max number of models that will be concurrently held in the LRU cache** \\(**glide.workflow.model.cache.max**\\) property. You must restart the instance to apply this change.\n\n"}}