ATF - Shared Parameter on Test basis

[Shan C]

Currently, once we enable the "Parameterized Test" option on a test, all shared parameters defined in the system automatically become available and show up in that test.

Is there anyway ServiceNow allows to remove or add existing shared parameters on test basis? If another team(say ITSM) don't want to see the shared parameters defined for my tests (say HRSD), no option to remove without deleing the shared parameter itself which would remove all the tests' references. I don't want to add exclusive parameter every time.

Any inputs would be helpful.

[Shan C]

I understand and that's how I have been using to avoid confusion. Thanks.

[Sardash]

@Shan C - If this helps then please mark it by selecting "Accept as Solution" and Close the thread 🙂
 

[VJ_Srivastava]

Hello @Shan C,

From an enterprise architecture perspective, the behavior you are experiencing highlights a classic tension between global reusability and domain isolation within a shared platform.

When ServiceNow designed ATF Shared Parameters, the intention was to create a repository of truly universal variables—things like standard test users, global location codes, or environment URLs. When disparate development teams (like ITSM and HRSD) begin dumping domain-specific variables into the global shared parameter table, it results in "global namespace pollution."

To build a scalable and maintainable testing architecture, I strongly advise implementing a strict governance model around ATF parameterization:

• Define "Shared" vs. "Exclusive": A parameter should only be promoted to a "Shared Parameter" if it is verifiably used across multiple platform domains (e.g., used by both ITSM and CSM). If a parameter is exclusively used by the HRSD team for their specific catalog items, it must remain an Exclusive Parameter, regardless of whether they have to create it multiple times for different HR tests.

• Data Set Abstraction: Rather than relying on a massive list of shared parameters, focus on architecting robust Parameter Data Sets. The complexity of test inputs should live in the data sets (the rows of data), not in the parameter definitions (the columns).

Attempting to customize the ATF UI to hide global variables from specific teams introduces unnecessary technical debt. Instead, correct the architectural anti-pattern by enforcing strict guidelines on what qualifies as a global shared variable.

[NehaG8791370651]

Hi @Shan C,

This is a very common frustration for teams scaling their Automated Test Framework (ATF) usage! Technically speaking, ServiceNow does not provide an out-of-the-box (OOB) way to filter or restrict sys_atf_shared_parameter records on a per-test or per-application basis. By design, checking the "Parameterized Test" box globally exposes all shared parameters to that test.

Because of this hardcoded platform behavior, you have to engineer around the UI limitations. Here are the most practical technical approaches to handle this without creating exclusive parameters for every single test:

• Strict Naming Conventions (Recommended): Since you cannot hide them, sort them. Implement a strict naming taxonomy for all Shared Parameters using application prefixes (e.g., [ITSM] Category, [HRSD] Profile Type, [GLOBAL] Impersonation User). This allows developers to quickly filter the parameter list or rely on type-ahead search without getting confused by cross-departmental variables.

• Avoid Query Business Rules/ACL Hacks: It is extremely tempting to write a Query Business Rule on the sys_atf_shared_parameter table to restrict visibility based on the user's role or scope. Do not do this. ATF relies heavily on system-level execution contexts. If you restrict read access to shared parameters via ACLs or Query BRs, you risk breaking automated test runs when the test executes as a system user or during a scheduled suite run.

• Parameter Consolidation: Review your shared parameters to see if they are truly distinct. Often, an ITSM "Category" and an HRSD "Category" can just be a single, global "Category" parameter that accepts different string values during the parameter data set configuration.

Keeping the OOB architecture intact while enforcing strict naming governance is the safest technical path forward!

[masonreed11]

It looks like there’s no supported way to hide a shared parameter for only one test. Shared parameters are automatically available to all parameterized tests, so using exclusive parameters is currently the practical workaround. A per-test include/exclude option would be a useful enhancement request to ServiceNow.