--- title: "FieldBuddy Development Process Information" canonical: "https://help.fieldbuddy.com/space/FBDOCS/5556436995/FieldBuddy%20Development%20Process%20Information" format: markdown --- At FieldBuddy we value the input of customers. In this document, we explain how customers can request new features and what’s the process behind it. > ℹ️ Are you experiencing a problem that is possibly a bug? Contact your partner or our support team. This guide is about feature requests, releases, roadmap and planning. ## Configuration vs. Feature Request There are two ways to accomplish a requirement from a customer in FieldBuddy: 1. The requirement can be configured by the partner using the **configuration** tools in our platform 2. The requirement requires **changes in the core** of the application, in FieldBuddy itself. It depends on the requirement whether it can be accomplished via the tools in the platform or not. Our solution is highly flexible, but there’s a limit. And in that case, a change is required in our application. Determining whether the requirement can be accomplished via configuration or not is often a discussion between the customer and the FieldBuddy partner. In this document, we assume that a **change **is needed **in the core** of the application. The requirement is now transformed into an ‘feature request’. ## Submitting feature requests An idea for a new feature of the FieldBuddy application can be submitted via the [customer portal](https://help.fieldbuddy.com/portal/3?createRequest=true&portalId=3&requestTypeId=42). A FieldBuddy partner can also do this on behalf of the customer. It should have the following information: 1. In what **application **is the feature required? 1. FieldBuddy Service Center 2. FieldBuddy Swift 3. FieldBuddy Customer Portal 4. FieldBuddy Dispatch Panel 5. FlexConnect 2. A description of the **problem** that you would like to be resolved, for example, ‘currently it's a lot of work and clicks to have an overview of a historical work order’. 3. A description of the idea that **resolves** the problem, for example: ‘a button in the mobile application that allows users to see an overview of the Work Order directly from the related tab’. 4. Optionally a mock-up or screenshot. ## Processing the feature request Our FieldBuddy support team will process the feature request and potentially ask for additional input. After that, it will follow these steps: > ℹ️ [OPEN] → [IN REVIEW] → [DONE] (Rejected, Backlog or Roadmap; can be the resolution reasons) 1. An initial scan of the feature request will be done to understand the requirement. The idea can be rejected at this stage. Often questions are asked to the customer to understand the problem and or the feature request. - Note: In the case of a rejection, we will explain why this idea will not become a feature in FieldBuddy. 2. The feature request will be scheduled in the FieldBuddy Product development meeting and discussed. It can be the situation that a feature request is postponed or grouped with other features* *in a dedicated meeting. 3. In the FieldBuddy Product development meeting the details, high-level impact, business value and estimated effort are determined for the feature request. 4. If accepted by the Product Owner, the feature request is transformed into one or multiple roadmap items. 1. In the case that the feature request is accepted, but it is not scheduled. It will be added to the ‘Backlog’. Feature requests will remain there up until they are selected to be developed. In which they move to the ‘Roadmap’. 2. In the case that the feature request is accepted, and directly added to the roadmap. A link will be shared to the item on our [public roadmap](https://help.fieldbuddy.com/page/roadmap). 5. The feature request will be set to ‘Done’ in the support portal since the request has been done and processed. A customer can monitor the roadmap or the feature request in the portal to see its progress. The stages an accepted feature request will go through are: [Backlog] → [Roadmap] → [RESOLVED]. > ⚠️ A feature request on our backlog does not have a schedule or planning. Only if its added to our roadmap, a planning is available. ## About the Roadmap Our roadmap is a planning that can be found [here](https://help.fieldbuddy.com/page/roadmap), its a list of items describing new features. Our release method is [release early, release often](https://en.wikipedia.org/wiki/Release_early,_release_often). Read more about it [here](https://upperdeck.atlassian.net/wiki/spaces/FBDOCS/pages/5262802967/What+is+FieldBuddy#Releases-%26-Updates). | **Stage** | **Description** | **Scope** | | --- | --- | --- | | Recently Done | A list of items that recently has been released | | | Now | A list of items that is currently being available for [fast-ring users](https://upperdeck.atlassian.net/wiki/spaces/FBDOCS/pages/5994807308) or customers | ~80-100% fixed | | Next | A list of items that is next one to be developed. | ~60% fixed | | Future | A list of items that will be done in the future. The order of these versions can change. | ~40% fixed | > ⚠️ The target window of the version can be found on the roadmap item by clicking on it. ### Release A release is a new version of our software, its a compilation of one or multiple items from our roadmap and often some bug fixes. The release is announced on the [release notes](https://help.fieldbuddy.com/page/release-notes) page. ### Item An item on our roadmap is a compilation of multiple feature requests and bugs. ### Scope The scope of a release are all the feature requests that are within that particular release. The scope of the release can change during development due to our [Agile](https://nl.wikipedia.org/wiki/Agile) way of working. This can impact that the feature request is removed from the scope and moved back to the backlog. ### Target window A version has a target window, depending on the complexity and estimated effort. The target window of a release can be found on the roadmap item. # FAQ **When will my feature request be released? ** Make sure you have a registered case in our customer support portal. This way you can track the progress of your feature request and ask questions. **What is the current roadmap?** Find our public roadmap [here](https://help.fieldbuddy.com/page/roadmap). **What is the planning?** Our planning is our roadmap. Read the [roadmap](https://help.fieldbuddy.com/page/roadmap) information to learn more. **What does it mean that my feature request is ‘on the backlog’?** That your feature request is accepted as a valid idea to be developed. When the feature request is not yet on our roadmap then there’s no information in terms of when it will be developed. This can be a matter of months, even years. **Will I be informed when my feature request is released?** Please subscribe to our [release notes](https://help.fieldbuddy.com/page/release-notes). **What about bugs?** This document is about feature requests. Bugs can be reported via the [customer portal](https://help.fieldbuddy.com/page/support). Once the bug is acknowledged and based on the impact, frequency, priority and if a workaround is available a bug will be assigned to a version or a (dedicated) patch is released to resolve the issue.