You are viewing limited content. For full access, please sign in.

Discussion

Discussion

[Feature Request] [Forms 11+] Form Component Library

posted on February 24

Hi team,

This idea has been rattling around in the back of my head for a while regarding enterprise use on premise, and recently has become more of a need rather than a want as competing platforms start to implement a similar approach in an effort to speed up solution building for citizen developers.


The suggestion I'd like to make is to create a forms component library, where users can define a reusable component (think a section) that contains fields, lookups and field rules which can be imported into any form.


Some key features would be:

  • Components are self contained within a 'block' (or section), and include preset variables, field rules and lookups.
     
  • Components should have two operating modes: Unlinked (default) / Linked. 
    • An unlinked component (default) is a block of fields with preset variables, rules and lookups contained within a section. These fields are inserted into the designer like a template, and can be freely renamed, modified / reorganised / removed at will. If the same block is dropped a second time onto the Canvas, the user is prompted on how they wish to name the variables since the fields and rules will already exist from the first component dropped onto the form. Options should be: Individual/Prefix/Postfix. Default is postfix “_1”.
    •  A Linked component is a read-only block that is connected 1:1 replica of the master component. The “section” container can only be moved around the form and the encapsulated field order, variables, labels, settings etc cannot be edited/changed or modified at the form level. These must be maintained at the component editor. More on this later.
       
  • Components should have different access / permission levels:
    • Default (Owner: Read/Update/Delete)
    • Select Users (Specified Users: Read/Update/Delete)
    • Team - (Team Admin: Read/Update/Delete, Team Member: Read)
    • Site Access - (Read/Update)
       
  • Linked components are a great way provide certain users, teams or departments with complex forms “components” that should always be the same across any form. A classic example of this is an “Active Directory” user lookup. There are fields such as the user, plus their manager, potentially branch and/or department that would best follow a set naming convention and order to maintain consistency. Rules and lookups should also be restricted from being changed as they may be too sensitive information sources that should only be configured by a component owner.
     
  • If a Linked component is dragged onto a canvas where a variable is already in use (e.g. there is a conflict) the user should be prompted to change the name of the conflicting variable. Variables for linked components must remain unchanged.
     
  • In order to maintain components, it would make sense to have a Component Editor. From this component editor you could configure the necessary permissions and be able to see where components have been used across the system. More importantly, from here you are able to publish changes to Linked Components. This is important because in some cases, you may be updating a Linked Component that could contain breaking changes. So when publishing an update, you should be given the option to “Save As” a new component, and then select which processes that currently use the Component will use which version of the component. Because you may have changed variable names, or introduced or removed fields, being able to identify and control which processes would require updating is essential.
     

That’s all I can think of right now, I’m sure some others will have ideas of their own to contribute but this would be a massive time saver and point of difference vs the common competitors (however, Microsoft’s Power Platform is already doing this).

CC: @████████

@████████ @████████ @████████

5 0
replied on March 5

This sounds like a great idea. This will make standardising multiple large processes much easier. 

2 0
replied on February 27 Show version history

Excellent idea Kris - agreed on all fronts.

The Active Directory one would be a huge deal, and a big time saver; but I'd add a Laserfiche Users (LFDS) component as well - so that there would be a 'component' that would look at LF Users/Groups (which may still be populated by AD, but are frequently segregated differently) as well as component that used true AD look-up as well.

Thinking further - a Laserfiche Forms Team component would also be superb - that had up-to-date Forms Team references so that users can select a Team and/or users from a Team, Roles etc.

1 0
replied on February 27

I think you're onto something here Duncan! Perhaps branch this out as a new idea for improvements to Lookup Functionality. Specifically, the ability to "lookup" as you say, LFDS Teams/Users and return some properties to a form that can then be acted on in the process modeller. 

That way, using the Components idea, you could bundle a few fields together, create the lookup rules (to LDFS) and then turn it into a "Team Selection" or "User Selection" /linked/ component for use by the designers and process administrators (where allowed).

1 0
replied on February 24

Hi Kris, 

    Thanks for sharing your ideas with us, we will take a deeper look and see what we can do. 

3 0
You are not allowed to follow up in this post.

Sign in to reply to this post.