I have a site under development that has subsections implemented using organic groups. There may be 1000 or more organic groups as the site scales. I'd like each group to have two workflows that may be customised by the admin users in that group. My approach has been to duplicate two existing 'base' workflows ('document_workflow' and 'issue_workflow') when a new group is created to get the users started with default workflows ('document_workflow_GROUPID' and 'issue_workflow_GROUPID'). Even though the particular workflow specified on the workflow field field instance refers to the base workflow, if I programatically set the new nodes to a state within the relevant GROUPID workflow there doesn't seem to be a problem (all setting is done via a custom UI). The users within that group can then edit the those group workflows, including the states and transitions as they please. I've extended the Workflow entity to contain a property referencing the group ID to achieve this.

My question is: will I encounter any scaling issues with this approach? The obvious one to me would be the UI at 'admin/config/workflow/workflow' getting very long, although I plan not to make this accessible to users. Are there any more 'internal' things that could start to break down?

Each Workflow has about 5 WorkflowStates, meaning I will end up with 2 workflows * 1000 groups * 5 WorkflowStates = 10,000 WorkflowStates.
Each Workflow has about 25 WorkflowTransitions, giving 2 * 1000 * 25 = 50,000 WorkflowTransitions.

Separately, I also considered adding fields to the workflow transitions to record some extra transition details, but realised this would create 1000+ field instances. Although Drupal 7.22 handles field caching better, this doesn't seem like a good idea to me, so I have decided to use a field on the same bundle as the workflow field sits instead to track the required info.

Thank you very much.

Comments

anthonys created an issue.