Forum Discussion
Copilot Agent ALM and Knowledge Source Management Across Environments
Hello everyone,
I currently have an agent in a Dev environment and want to deploy it to a second environment (e.g., Test or Prod).
During deployment, we need to change the references to the knowledge sources. I’ve seen some articles where environment variables are used within Conversational Boosting topics to handle this, but I wanted to check if there is a supported or recommended way to manage or update knowledge source references from the Knowledge section itself to make them dynamic by using Environment variable?
Any guidance or best practices would help. Thankyou.
1 Reply
hi RakeshPanwar Great question, this is a very common challenge when you start treating Copilot agents as real applications with proper ALM.
Short answer: today there isn’t a fully supported way to parameterize knowledge source references directly in the “Knowledge” section using environment variables. Knowledge sources (SharePoint sites, files, Dataverse tables, URLs, etc.) are currently bound at design time to the environment where the agent is created.
A few clarifications based on current behavior and guidance:
What does work today
Environment variables inside Conversational Boosting / topics
This is the only supported pattern right now if you need environment-specific values (URLs, endpoints, IDs). It works well when your agent logic explicitly references those values during runtime.
Environment-specific agents
The recommended approach today is still:
Dev agent → Test agent → Prod agent
Each environment has its own knowledge sources configured natively
Use managed solutions / pipelines to move the agent structure, then rebind knowledge in the target environment
What does not work (yet)
Making Knowledge section sources themselves dynamic via environment variables
Automatically “retargeting” SharePoint / Dataverse knowledge sources during solution import
A single agent definition that dynamically switches knowledge sources at runtime based on environment
Practical ALM guidance (what most teams are doing)
Treat knowledge sources as environment-specific configuration, similar to connection references
Keep:
Prompts, orchestration, topics → solution-managed
Knowledge bindings → reconfigured per environment
Document (or script where possible) post-deployment steps to reconnect the correct knowledge sources in Test/Prod
Forward-looking note
Microsoft has been steadily improving Copilot/Agent ALM, but knowledge source portability is still an area with gaps. Based on current direction, many expect:
Better separation of agent logic vs environment bindings
Knowledge source rebinding as part of deployment pipelines (similar to connection references), but as of now, it’s not officially supported.
