> For the complete documentation index, see [llms.txt](https://docs.novacura.com/flow-connect/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.novacura.com/flow-connect/working-with-connect/connect-to-systems/custom-functionality.md).
# Custom Functionality
You may encounter requirements that standard Flow Connect functionality can't address. In these cases, you can extend your solution with custom functionality.
The recommended approach depends on what you need to achieve and where the custom functionality needs to run.
### Start with the PowerShell Connector
If the [PowerShell Connector](https://docs.novacura.com/flow-connect/working-with-connect/connect-to-systems/connectors/powershell) can solve your requirement, it is generally the simplest and fastest approach.
If PowerShell isn't suitable, you can build your own service and expose the required functionality through a REST API, which Flow Connect can then call using the REST Connector.
How you decide to build your own service depends on what you are trying to achieve, so we can't provide general guidelines. An LLM can likely generate the code at this stage, but consider consulting a software engineer to ensure proper security and reliability measures are in place if you plan to use it in production. The key is to wrap your service in a REST layer so you can set up a REST Connector in Flow to talk to it.
If you host your Connector agent on a server, you can also host your solution there for performance, simplicity, and security. But be extra careful not to fill up disks or overconsume its resources, as it could affect your critical business processes.
The decision flow below outlines the options.
### Hosting a custom REST service
If you build a custom REST service, there are two main hosting options.
#### Host the service locally
If the service is used only by Flow Connect, it can be hosted on the same server as the **Connector Agent** and bound exclusively to the local loopback interface (`localhost` / `127.0.0.1`).
In this setup, HTTP may be used alongside Bearer Token authentication, provided the service is accessible only from localhost. Because communication remains on the local machine, there is no network transport to protect with TLS.
If the service is exposed beyond localhost, HTTP should not be used. Use HTTPS instead.
> **Agent Groups**
>
> If the REST Connector uses an **Agent Group containing multiple Agent servers**, a locally hosted service must be deployed and maintained on each server in the Agent Group. Requests may be executed by any Agent in the group.
#### Host the service externally
If the service needs to be accessible over a network, from multiple Agent servers, or by other systems or users, host it in the cloud or on another suitable server.
In this scenario, expose the service using **HTTPS with a valid TLS certificate** and appropriate authentication, such as Bearer Token authentication, together with any additional security controls required for your environment.
The hosting overview below illustrates the differences between the local and external approaches.
### Responsibility for custom solutions
Custom solutions are outside the standard Flow Connect functionality and must be maintained by you.
This includes, where applicable:
* backups
* application and dependency updates
* security patches
* certificates and certificate renewal
* security configuration
* monitoring and operational maintenance
* keeping the underlying technology stack on supported versions
For example, if the custom service is built using .NET, it should be upgraded when the .NET version it uses reaches end of support.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.novacura.com/flow-connect/working-with-connect/connect-to-systems/custom-functionality.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
