Partial Locking

THIS FEATURE IS CURRENTLY IN BETA

Introduction

While the customers face challenges in customizing their applications to meet their unique needs, they are often forced to choose between relying on end-user customizations for their application enhancements or having no room for even minor configuration changes. The existing functionality posed a limitation, for example - relabelling picklist values. Customers are forced to either forgo improvements made by the original developers or accept extremely limited configuration options.

To address these challenges, Infinite Blue Platform has now introduced three types of application lock options:

  • Locked: This setting ensures that the entire application remains untouched in the destination tenant, creating a genuine Software as a Service (SaaS) experience.

  • Partially Locked: Administrators can selectively lock or unlock specific components within an application, offering a balance between customization and control.

  • Unlocked: This option provides complete customization freedom but effectively prevents future upgrade paths or enhancements.

With Partial Locking, Application Publishers/ISV providers can design configurable applications, ensuring customized configurations remain intact during upgrades. With granular control over customization elements and preserving vital integrations with application upgrades. With this mechanism, emergency application updates can also be swiftly deployed without destabilizing the system.

Likewise, the end user can also benefit from a customized environment where components can be tailored effortlessly. They can manage versions effectively, selectively adopt changes, and have the flexibility to decide when to upgrade. This approach ensures a seamless transition while preserving custom settings.

For detailed information, see Partial Lock Preferences.

Use Case

Managing partially locked fields

This use case outlines the process of configuring field settings in the source application while ensuring the persistence of these configurations in the tenant destination after application updates.

In the source application, the length of the Employee ID field is set to 100 characters. This field will be set to partially locked which should allow for further configurations in tenant destination.

In the Partial Preferences page, it is evident that the Employee ID field is set to Partially Locked.

Upon installing the updated application in the tenant destination, the configuration options are now accessible to the tenant destination. The length of the Employee ID field is changed to 8 characters, from the previous setting of 100 characters by the tenant.

However, the source application creator modifies the Employee ID field by adding a Default Value. These modifications are subsequently pushed to the tenant for implementation.

However, post-update in the destination tenant, the configurations established by the tenant application remain unchanged. The latest modifications made by the original application creator to the Employee ID field are considered, indicating a restraining update to the specific field.

Despite the application creator's attempts to modify the Employee ID field, the configurations established by the tenant in the destination remain unchanged, emphasizing the flexibility given to tenants for a seamless update process.