Workflow / Form Builder Security Now Honors Category Permissions
A change has been made to how Workflow Type security is evaluated. Workflow Types (including those created through Form Builder) now inherit security from their Category (folder) when permissions are not explicitly defined on the workflow itself.
Previously, permissions configured on a Category were not recognized as inherited permissions by the Workflow Type. This created inconsistent behavior across the system. For example, a team granted Edit access to a folder could edit a form inside Form Builder, but they could not clone or delete it.
This update resolves the inconsistency by making Workflow Types inherit security from their Category, which is now treated as the parent security authority for the workflow. Administrators can now manage permissions at the folder level and have those permissions applied consistently to the workflows contained within that category.
Also note that the Workflow Type Detail block on the Workflow Configuration page still requires "Administrate" role to delete a workflow type from there.
Important Note About Category Permissions
Because the Category is now treated as the parent security authority, individuals with Edit permission on a Workflow Category can also modify the category itself and manage items within it. This includes deleting workflows and deleting the category if it does not contain any workflows.
Organizations that delegate workflow management to teams should review their Workflow Category security settings to ensure the appropriate groups have Edit access.