Service Portal widgets: how do you handle parallel development and conflicts?

Rafael Batistot
Kilo Patron

3 weeks ago

 

Hi everyone,

 

I’d like to bring up a topic that I believe many Service Portal developers have faced.

 

When working with Service Portal widgets, especially when multiple developers are editing the same widget (same scope, same instance), changes become visible immediately to everyone as soon as the widget is saved.

 

Even when each developer uses their own Update Set, there is no isolation the widget record (sp_widget) is shared.


Is there any recommended way to handle or mitigate this situation?

For example:

 

  • Do you use widget cloning?
  • Separate DEV instances?
  • Source Control / GitHub in any effective way?
  • Or is this mainly handled through team process and coordination?

 

If you found this response helpful, please mark it as Helpful. If it fully answered your question, consider marking it as Correct. Doing so helps other users find accurate and useful information more easily.
0 Helpfuls
  • 281 Views
1 REPLY 1

Itallo Brandão
Tera Guru

3 weeks ago

Hi @Rafael Batistot ,

You have touched on one of the classic "pain points" of Service Portal development. Since the sp_widget record is metadata residing on a single database, there is no true "runtime isolation" on a shared instance. If you save a syntax error, you break the widget for everyone instantly.

While Source Control (Git) is great for versioning, it handles the Instance state, not individual User sessions, so switching branches affects everyone on that instance.

Here are the three proven strategies to handle this, ranked from Best Practice to Process Workarounds:

1. Modular Architecture (The "Divide and Conquer" Strategy) The most effective technical solution is to avoid building "Monolithic Widgets" (God Widgets) where all HTML, Client Script, and Server Script live in one massive record.

  • Angular Providers: Move your heavy logic, HTTP calls, and data processing into Widget Dependencies (Angular Providers/Factories). Developer A can work on the Provider logic while Developer B works on the Widget UI.

  • Embedded Widgets: Break your UI into smaller, reusable components. Use sp_widget directives to embed them.

    • Example: Instead of one huge "Homepage" widget, build a container widget that embeds a "Header Widget," a "List Widget," and a "Footer Widget." Now three developers can work in parallel on the same page without touching the same record.

2. The "Sandbox Clone" Method If two developers absolutely must modify the exact same complex widget simultaneously:

  1. Clone it: Developer B creates a copy: MyWidget_Sandbox_Raf.

  2. Isolate it: Place this clone on a private Test Page.

  3. Develop: Developer B works freely without breaking the main widget for Developer A.

  4. Merge: Once done, Developer B manually copies the code changes back into the Main Widget (or uses a merge tool like Beyond Compare locally).

3. VS Code Extension (Conflict Awareness) If you aren't using the ServiceNow Extensions for VS Code, you should start.

  • It allows you to edit widgets locally.

  • While it still syncs to the server on save, it makes it much easier to pull the latest version before saving, reducing accidental overwrites.

  • It provides a better environment to spot if someone else updated the record since your last pull.

Summary: Technical isolation on a single instance doesn't exist. The solution is Componentization (breaking the widget down) combined with good communication ("I'm locking this file for 1 hour").

If this response helps clarify the approach, please mark it as Helpful.

Best regards,
Brandão.