There seem to be three-four perspectives to rending forms, just curious what Flowable’s thoughts are on this topic:
Field Values - Workflow cares about the values provided by the user, but doesn’t care what they’re publicly called or how they’re presented to the user.
Localization of Text - Headless CMS Platforms allow the concept of a form to be broken out into several fields. But then provide their own governance workflows and translation facilitation.
Mashup Values and Localization - Combine the management of these two views of the form together.
Presentation Layer - Render this to an end user using Angular.
Here’s the object model for one such HCMS product:
• Content Type (class)
• Entry (object) – The layer that facilitates governance.
• Fields - Individual fields.
I’m not clear on the benefits of adding in a headless CMS over just using the Flowable BPM and Forms engine. The BPM can address individual form fields, so things can be done with individual field values as part of an overall process. Alternatively, the forms engine can have client-side behavior, which could be calling microservices or even other processes over REST (for example).
Maybe a more full example of what you’re thinking about would make it easier to be specific in possibilities.
These days, an ECM (headless or not) really only adds value if you need 100s of million files managed. Otherwise, most ECMs (even the “modern” ones) introduce a big overhead.
Just my thoughts, others are very welcome!
Sure, I’m learning that Content Management means different things to different people. I’m curious to hear more about the Flowable Localization story. Typically, CM refers to a pile of artifacts (Word or Rich Text, Audio, Video etc.) If a workflow results in sharing an artifact, that’s definitely part of our use case. But we would also want to design a single BPMN flow and have that work for several different languages. So that both the form and the artifact are rendered with the appropriate language. If a workflow is initially designed in English and then gets made available to a French audience, we don’t want to miss translating a piece of content. The content ends up being work direction. It’s quite possible we’ll have thousands of pieces of content.
Here are some of the features that seem to be associated with HCMS, that we’ll need to support:
- Breaking a given form/page into multiple fields
- Retrieving that entire form/page worth of fields from a secure REST API.
- Tracking content governance of that form. Content Originator Signoff, Content Reviewer Signoff etc.
- Localizing that document/form into different languages.
- Looking for ways to ensure that the URL’s that might be included in content do not currently generate a 404 error. As content count increases, this is something that needs to be automated.
Ok, I understand better now. To be honest, I think an ECM is overkill for that use case. You could do something much more simply with a DB and a little work. Then have management processes operating tangentially to the actual form flow business process that look after translation processes for the form labels and text. We have other options on the enterprise side but that’s not for discussion here.