UI does not launch std:account:disable and std:account:enable of custom SaaS connector

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi,
I have developed a custom SaaS connector (as per Test, Build, and Deploy | SailPoint Developer Community) and when I run the “Disable account” or “Enable account” in the UI, the std:account:disable or std:account:enable are not called. Note: std:test-connection, std:account:list and std:account:read work through the UI.

My connector spec contains the declaration of the commands:

"commands": [
	"std:account:list",
	"std:account:read",
	"std:account:enable",
	"std:account:disable",
	"std:test-connection"
]

and the code implements each of the corresponding functions:

import {
    Context,
    createConnector,
    readConfig,
    Response,
    logger,
    StdAccountListOutput,
    StdAccountReadInput,
    StdAccountReadOutput,
    StdTestConnectionOutput,
    StdAccountListInput,
    StdTestConnectionInput,
    StdAccountDisableInput,
    StdAccountDisableOutput,
    StdAccountEnableInput,
    StdAccountEnableOutput
} from '@sailpoint/connector-sdk'
import { MyClient } from './my-client'
import { toStdOutput } from './tools/utils'

// Connector must be exported as module property named connector
export const connector = async () => {

    // Get connector source config
    const config = await readConfig()
    
    // Use the vendor SDK, or implement own client as necessary, to initialize a client
    const myClient = new MyClient(config)

    return createConnector()
        .stdTestConnection(async (context: Context, input: StdTestConnectionInput, res: Response<StdTestConnectionOutput>) => {
            logger.info("Running test connection")
            res.send(await myClient.testConnection());
        })

        .stdAccountList(async (context: Context, input: StdAccountListInput, res: Response<StdAccountListOutput>) => {
            logger.info("Running account list")

            const accounts : Array<any> = await myClient.getAllAccounts()
            
            for (const account of accounts) {
                res.send(toStdOutput(account));
            }
            logger.info(`stdAccountList sent ${accounts.length} account(s)`)
        })

        .stdAccountRead(async (context: Context, input: StdAccountReadInput, res: Response<StdAccountReadOutput>) => {
            logger.info("Running account read for: " + input.identity)

            const account = await myClient.getAccount(input.identity)
            res.send(toStdOutput(account));

            logger.info('stdAccountList sent 1 account: ' + input.identity);
        })

        .stdAccountDisable(async (context: Context, input: StdAccountDisableInput, res: Response<StdAccountDisableOutput>) => {
            logger.info("Running account disable for: " + input.identity)

            const account = await myClient.disableAccount(input.identity)
            res.send(toStdOutput(account))

            logger.info('stdAccountDisable disabled the account: ' + input.identity);
        })

        .stdAccountEnable(async (context: Context, input: StdAccountEnableInput, res: Response<StdAccountEnableOutput>) => {
            logger.info("Running account enable for: " + input.identity)

            const account = await myClient.enableAccount(input.identity)
            res.send(toStdOutput(account))

            logger.info('stdAccountEnable enabled the account: ' + input.identity);
        })
}

When running the connector locally npm run dev and using Postman to send the API calls, std:account:disable and std:account:enable work fine.
But when running it from the source in the UI, I see in the connector logs that those commands are not launched.

2025-06-06T08:55:26.337-04:00] INFO  | createVersion    ▶︎ created new connector version: 20
[2025-06-06T08:55:26.443-04:00] INFO  | updateTag        ▶︎ updated connector tag latest to version: 20
[2025-06-06T08:55:36.496-04:00] INFO  | invokeCommand    ▶︎ Command execution started : std:account:list, for connector version 20.
[2025-06-06T08:55:37.385-04:00] INFO  | connectorMessage ▶︎ {"commandType":"std:account:list","invocationId":"2adc5f7f-fbfc-4693-a437-ee492fe09733","message":"Running account list","requestId":"c23436bd84264f79bda82d49c62c876a","version":20}
[2025-06-06T08:55:38.021-04:00] INFO  | connectorMessage ▶︎ {"commandType":"std:account:list","invocationId":"2adc5f7f-fbfc-4693-a437-ee492fe09733","message":"stdAccountList sent 105 account(s)","requestId":"c23436bd84264f79bda82d49c62c876a","version":20}
[2025-06-06T08:55:38.028-04:00] INFO  | commandResponse  ▶︎ Command response processed: std:account:list, for connector version 20. output_count=100 output_bytes=25390 keep_alive_count=0 state_count=0. Elapsed time 1326ms
[2025-06-06T08:55:38.050-04:00] INFO  | commandOutcome   ▶︎ Command completed: std:account:list, for connector version 20. output_count=105 output_bytes=26668 keep_alive_count=0 state_count=0. Elapsed time 1348ms

Any idea why it does not work?

Thank you.
Julien

2

Hi @jboninfante

I can see “std:account:disable” and “std:account:enable” are not triggered unless explicitly defined in the provisioning policy. Check once

Thanks
Manvitha.Nalabolu

3

Thank you! I will check and let you know.

4

Hi @Manvitha.Nalabolu, the provisioning policies for the sources were indeed empty. I added one for the DISABLE and another for the ENABLE operations:

[
    {
        "name": "Provisioning policy to enable zzz",
        "description": "This policy enables zzz",
        "usageType": "ENABLE",
        "fields": []
    },
    {
        "name": "Provisioning policy to disable zzz",
        "description": "This policy disables zzz",
        "usageType": "DISABLE",
        "fields": []
    }
]

and even with them, the UI never launchs the disable or enable command.

5

You shouldn’t need to add Provision Policies for Disable and Enable, unless you are trying to do something special like provision a particular attribute during the Disable/Enable.

Do the UI logs show that you initiated a disable or enable?

6

That’s the problem: I don’t see in the connector logs that the disable or enable commands are send. In the UI, however, it shows that is starts the command, says pending for a while and then said completed, but nothing happened.

7

Your index code and connector-spec commands look fine.

Have you changed the connector-spec file commands since you created the Source in your tenant? If so, those changes will not get reflected in the Source and the commands will not run. You will need to either manually update the Source config features via API, or just delete and recreate the Source.

Even if you haven’t changed the connector-spec file, you might want to delete and recreate the Source to make sure there isn’t something weird stuck.

1 Like
8

Thank you very much, @Carlatto , recreating the source alone did not solved the problem.

I worked with @brennenscott from the SailPoint Architect team and he was able to solve the problem.

The issue came from the fact that the PROVISIONING feature was not added to the source during its creation, therefore ISC was not attempting to perform any disable operations.

To resolve this, we added the std:account:create command to the connector-spec.json file, even I did not implement the corresponding function in the connector. The new command section of the connector-spec.json looks like:

"commands": [
	"std:account:list",
	"std:account:read",
	"std:test-connection",
	"std:account:disable",
	"std:account:enable",
	"std:account:create"
]

Also, as @Carlatto rightfully mentioned, it appears that some of the sections of the connector-spec.json like schema and commands are not refreshed when uploading a new version of the connector. So to get the changes applied, the source must be deleted, the connector must be deleted from the tenant and recreated, then the source must be recreated.

$ sail conn delete -c <connector name|connector id>
$ sail conn create -c <connector name|connector id>
$ sail conn upload -c <connector name|connector id> -f dist/<path-to-zip

Thank you very much to @brennenscott , @Carlatto and @ManvithaNalabolu06 for your help.

If you encounter this issue, I hope this post will help you solve it.

Julien

2 Likes
9

Glad you got it working. Thanks for the information that std:account:create enables the Provisioning feature.

1 Like
10

It was great working with you @jboninfante!

11

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.