Locking Custom Objects in SuiteCloud Development Framework

Locking custom objects within the SuiteCloud Development Framework (SDF) is crucial for maintaining data integrity during SuiteApp deployments. This approach enables developers to specify which objects can be altered in target accounts, preventing unauthorized changes. The locking.xml file is pivotal in managing these settings.

How to Lock a Custom Object Using SDF

To lock a custom object, you define preferences in the locking.xml file. Here’s how you can lock a custom list example:

<preference type="LOCKING" defaultAction="UNLOCK">
    <apply action="LOCK">
        <object>customlist_example1</object>
    </apply>
</preference>

In this example:

• The preference type is set to LOCKING.
• The default action is defined as UNLOCK, meaning that without explicit actions, the object remains unlocked.
• When an apply action of LOCK is invoked, the specified custom object (customlist_example1) will be locked.

Lockable SDF Custom Objects

The ability to lock varies depending on the type of custom object. Here’s a breakdown of the lockable SDF custom object types:

• Original custom field IDs remain intact. | | customsegment | Lock must apply to both the custom segment and its associated custom record type. | | crmcustomfield | Custom fields can have controlled access through form customizations. | | plugins | Locked plugins can still be configured, but their original fields remain unchanged. | | savedsearch | Users can create copies of locked saved searches to modify filters and columns. | | workflow | Certain basic information fields can be edited, but you cannot alter the workflow definition or its core actions. |

Considerations When Locking

• Custom Lists: Ensure all necessary values are in place before locking a custom list since no additions or deletions will be allowed afterward.
• Custom Record Types: Be aware that while you can create new instances of custom records, any IDs associated with original records cannot be manipulated.
• Plugins and Scripts: Locking allows for consistency in versions, but developers should plan for future configurations since original custom field IDs cannot be modified once locked.

Knowing what can be locked and the implications of doing so will help maintain ordered project deployments and prevent disruption in client operations. Always evaluate the need for locking against operational requirements before implementing these restrictions.

Who This Affects

• Developers: Those who create custom applications using SuiteCloud will find locking critical for maintaining structure.
• Administrators: Administrators managing SuiteApps should implement and oversee these locking settings.
• Technical Leads: Ensuring best practices in code deployment through structured object management falls to tech leads.

Key Takeaways

• Locking prevents unauthorized changes to custom objects in target accounts.
• Modify the locking.xml to apply and manage lock preferences effectively.
• Understanding the implications of locking different object types is essential for developers and administrators.