Usando parâmetros de projeto SSIS em trabalhos do SQL Agent

É como você diz, você só pode ter uma referência de ambiente em um projeto SSIS - o que é uma pena.

Suas opções são

1. Faça um único ambiente que todos os projetos usam para suas configurações. A vantagem é que está tudo em um único lugar e ajuda você a superar o problema que está enfrentando. A desvantagem é que todos os cookies estão em um único frasco, o que provavelmente não é um grande risco de segurança. Um problema mais provável é a comunicação organizacional. A pasta A/Project 1 tem uma string de conexão para OutputFile para C:\ssisdata\foo\bar\myfile.txt. A Pasta B/Projeto 2 é implantada e eles configuram uma string de conexão para OutputFile para C:\ssisdata\bar\blee\out.csv sem perceber ou se importar que eles destruíram a configuração do Projeto 1. Ops
2. Cada pasta tem seu próprio ambiente. A vantagem é que, novamente, você tem todas as configurações em um único lugar e está isolado de outras equipes que podem pisar em suas configurações. A desvantagem é que há mais administração envolvida. As credenciais da conta do serviço de vendas foram alteradas? Agora você tem que atualizar N Environments para refletir isso
3. Uma abordagem híbrida. Use o ambiente mais rico, como seu SalesforceProd e, em seguida, faça a configuração direta para o restante dos elementos do projeto. A boa notícia é que essa é uma tarefa única por projeto. As implantações de projeto subsequentes não redefinirão as configurações. A desvantagem é a mesma do nº 2, pois você precisa atualizar as configurações, mas agora em cada projeto quando um valor "compartilhado" é alterado.

E pelo que vale a pena, provavelmente não há necessidade de criar parâmetros explícitos para cadeias de conexão, pois você pode clicar na seção "Gerenciadores de conexões" na primeira captura de tela e configurá-los nessa tela. Isso permite que você corte algumas lógicas/expressões extras em seus pacotes e potencialmente evite o vazamento de dados confidenciais em logs ou algo parecido.