feat(servicenow): register action for incident listing

[drodil]

Hey, I just made a Pull Request!

Add action to servicenow plugin for listing incidents.

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)
• All your commits have a Signed-off-by line in the message. (more info)

[backstage-goalie]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@backstage-community/plugin-servicenow-backend	workspaces/servicenow/plugins/servicenow-backend	patch	v1.10.0

[ciiay]

Hi @drodil , thanks for the PR 👍

I have two safety concerns:

• Unscoped listing: When no entity name is provided, the action can query ServiceNow broadly using the integration account, which is a larger exposure than the authenticated /incidents route.

• Validation gap: The REST handler uses validateIncidentQueryParams (allowlisted state/priority/orderBy, etc.), but the action passes those fields straight into fetchIncidents. I’d like the same rules on both paths so we don’t widen risk (e.g. encoded-query edge cases).

Can we make registering this action opt-in (e.g. a servicenow.actions.enabled config flag, default off for the first release) so teams only enable it when they’re comfortable with Actions calling ServiceNow?

Longer term, if we add more ServiceNow actions, we could split them into a small dedicated backend module (similar to scaffolder-backend-module-servicenow) so adopters can opt in at the package level too. Happy to open a follow-up issue if that direction makes sense.

[drodil]

@ciiay good points, should we force the entity selection in the listing? The validation gap can also be fixed by using the zod enumeration for those fields.

All actions already require opt-in via config actions.pluginSources, so there's no need for additional plugin-specific config. Splitting them into modules might make sense in some cases, but usually, they are located directly in the backend package because it already has the necessary services (like database or other plugin specific services) for easy integration.

[ciiay]

Thanks for the quick follow-up and the changes 🤝 This lines up well with my earlier comment.

On your points

• Forcing entity selection: Agreed. Requiring name (and resolving via the catalog with credentials) is the right tradeoff and matches the “scoped listing” story.
• Validation: Using allowlists + IN… for state/priority and IncidentFieldEnum for orderBy is a solid fix and much closer to the REST path.
  • Optional polish: mirror the REST userEmail shape check for parity, and consider sharing the allowed state/priority lists with validator.ts so they can’t drift.
• Opt-in via actions.pluginSources: Good point. A short note in the plugin docs or changelog that enabling this backend as an action source exposes servicenow:list-incidents would still help operators.
• Keeping actions in this backend package: Agreed. Splitting isn’t necessary here given the existing wiring.

One thing to double-check in code (not introduced by the action alone):
The action now always passes u_backstage_entity_id into fetchIncidents, but DefaultServiceNowClient still doesn’t append u_backstage_entity_id to sysparm_query (it’s predefined so it’s skipped in the generic loop, and there’s no explicit branch). Worth confirming end-to-end against a real instance; if filtering isn’t applied, adding an explicit u_backstage_entity_id=… fragment in the client would make the forced-entity behavior actually hold in ServiceNow.

[ciiay]

These are duplicated to consts in validator.ts. We can extract these to reusable consts to avoid redundant.