Zetect Usage Guide Connector Guide
Switch portal ⇄
Home › Connector Guide › App Store Onboarding › New vs. Existing Application

New vs. Existing Application

Before you touch anything, decide which surface actually needs to change: the App Store (the application catalog) or the connector code. Picking the wrong one either onboards a duplicate application or ships code nobody's provisioning XML asks for.

The two paths

SituationWhat to do
Brand-new application, not yet in the App StoreOnboard it: create the Application record, mark it Provisioning, and upload a provisioning XML built for its connector. See connector-provisioning-xml for how to write and upload that file.
Existing application, connector needs a code-only fixUpdate and redeploy only the connector JAR (connector-build → connector-deploy). No App Store change at all — the existing Application record and its provisioning XML are untouched.
Existing application, the fix also exposes a new configurable fieldBoth: update the connector code and re-upload a revised provisioning XML on the Application's edit screen, so the new field actually has somewhere to be configured.

Why the App Store's XML is the source of truth

An application's Provisioning Config screens — Source, Account Attributes, Group Attributes and so on — are rendered dynamically from the FieldSet/Field/Attribute elements declared in its uploaded provisioning XML. Nothing about that rendering comes from the connector JAR itself; the JAR only implements the behavior behind CREATE_ACCOUNT, UPDATE_ACCOUNT and the rest. Two independent artifacts, two independent reasons to change them:

  1. The provisioning XML — declares which fields an admin sees and fills in for this application. Lives in the App Store, attached to the Application record.
  2. The connector JAR — implements what actually happens with those field values against the target system. Lives in the agent's connectors directory, per connector-deploy.

Decision checklist

  1. Search the App Store's Applications list for the target application. Not there? → new-application path: go to connector-provisioning-xml and onboard it.
  2. Found it, and the requested change is pure logic — a bugfix, a different API call, retry/backoff behavior, a transform that uses fields the XML already declares? → connector-code-only path. Skip the App Store.
  3. Found it, but the change needs an admin to configure something that has no field for it today (a new connection setting, a new attribute to map)? → touch both: extend the provisioning XML with the new Field/Attribute block, and implement the corresponding logic in the connector.
  4. Never create a second Application record to work around a connector change — a duplicate app fragments authorization, certifications, access requests and SoD rules that already reference the original.