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: @████████

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