Open ideas have been reviewed by our Product Management and are open for commenting and voting.
It would be helpful if the text editor supported more advanced formatting options to create a more professional-looking output, including line breaks, text styling, and font customization.
IssueThe Migrating From REST API V3 section currently documents new, moved, and removed endpoints, including V3-to-V4 endpoint mappings.However, it does not document changes to the attributes within each endpoint’s request and response.Customers must therefore compare the V3 and V4 Swagger definitions side by side to identify:Added, removed, or renamed attributes Changes to required and optional fields Changes to object nesting and response structure Changes to parametersThis makes migrations time-consuming and increases the risk of missed changes, integration failures, delayed upgrades, and support cases.Proposed solutionFor each endpoint mapping, include a concise table showing attribute changes. If no attributes changed, state: “No request or response schema changes”This should become a standard part of future major-version migration documentation, including V4-to-V5. BenefitsReduces migration time and manual comparison Prevents customers from overlooking breaking changes Makes upgrade effort easier to estimate Reduces testing, troubleshooting, and support cases Creates a consistent process for future API migrations
Hello,We are currently expanding the use of Apache Kafka across our organization, and more and more departments are requesting access to published topics.Unfortunately, I cannot use the Apache Kafka Connector in FME to publish data because our Schema Registry is protected by authentication. When the connector tries to access the Schema Registry, it fails with an "Unauthorized" error.As a workaround, I developed a custom Python script that publishes the data directly to Kafka. While this solution works, it is far from ideal. One of the main advantages of FME is that non-developers can build and maintain integrations without writing code. Not everyone in our department is comfortable with Python, so relying on custom scripts creates an additional maintenance burden.It would be great if the Apache Kafka Connector supported authenticated Schema Registries, allowing users to publish messages directly through the native connector without requiring custom Python implementations.Best regards,Felix 😊
Currently the translation log window starts with a messageCommand-line to run this workspace: "C:Program FilesFME2016.1.1fme.exe" someWorkspace.fmw --Param1 "Value1" --Param2 "Value2"but this information is not reflected in the log file itself, and unless you have a ParameterFetcher+Logger, you cannot easily recreate the settings of a workspace with just the log file.I would like an option in the Translation Log Settings to write the (published) parameter settings to the log file. Perhaps as part of the FME Configuration Inform messages?
Could you please add a simple “Copy FMW Full Path” feature in Workbench.I’m referring to: It’s a simple request but a valuable one as it will save me a lot of time. (i.e. resolving service desk calls / documentation / ...)
Hello everyone,in FME Flow, it is currently possible to create multiple Automations with exactly the same name.From a user perspective, this can become confusing quite quickly, especially because Automations are displayed in a flat list and there is no structure comparable to repositories. If several Automations have the same name, it becomes harder to identify the correct one, especially in larger environments with many users and many Automations.I understand that the internal identifier is an ID and not the Automation name, which is technically the right approach. I also understand that there may be valid scenarios where different users, with different permissions, create Automations with the same name and cannot see each other’s items.Still, it would be helpful to improve the user experience here. Possible options could be: warn the user when creating an Automation with a name that already exists and is visible to them prevent duplicate names within the same visible scope provide folders or a repository-like structure for Automations improve filtering or tagging options to make larger Automation lists easier to manage This would help avoid confusion and reduce the risk of users editing, starting, or referencing the wrong Automation.Would it be possible to consider this as a future improvement for FME Flow?
It's not always possible to print to a PDF, so it would be nice if you could export the entire workspace canvas as a graphic file for documentation purposes.
In the current situation + Finland & Sweden joining NATO there is more demand to support Nato Vector Graphics (NVG) -format. Just read a RFP where it’s a must and waiting for more similar RFP’s to come. It’s not just the military people who ask for it, it’s also e.g. border control and who ever is providing services for them.
Support readers/writers for Bentley's Open Roads, as many transportation agencies are using them.
Hi Safe team,I’d just like to suggest that it may be helpful if published text parameters in FME Flow Apps could support placeholder text inside the input box.Example: For an email parameter, the field could show name@company.com as hint text without submitting it as a real value.Right now the workaround is to put the example in the prompt or in the app description, but placeholder text would be cleaner and easier for users.This would help for email fields, IDs, dates, and other inputs where a format example is useful.Thanks for considering!I’ve added example images below to show the current behavior and the suggested improvement.Current:Place holder text example:
I’ve been using the CESIUM 3D Tiles transformer, and my experience has been somewhat tricky because of (I hope) the version that FME writes (1.0). I wonder if future versions of FME will support the 1.1 version to help resolve some issues I’ve encountered, such as the structure of the .json output or to be able to select the type of geometry compression, like Draco, Meshopt, or Quantization.
This idea has come up in the 2016 thread (now released) about adding any output ports to FeatureWriter but the use case for Rejected features remains - e.g. some web-based format has a transient HTTP error, the failed features need to be retried after a wee delay, or a field overflows and can’t be written. @markatsafe @rylanatsafe you guys were on that thread. FeatureReader has a Rejected port, very handy for retry logic in a looping custom transformer, lets see it for FeatureWriter!There might need to be a Rejected port for each output port if you're going to loop it, or filter on feature type before looping to an input.
I would like the ListSorter to support multiple sort-by criteria, similar to the regular Sorter. Example:Currently (FME 2018.0.1) you cannot use multiple ListSorters to accomplish the same thing, since the ListSorter doesn't preserve the existing item order on duplicate sort keys (PR83992).
I store multiple geometry columns in a single table. I'd like to be able to use the PostGIS Reader to decide which geometry I'd like to pull out and transform.
Please add support for reading PLY - Polygon File Format, a 3D model format, also known as the Stanford Triangle Format: http://paulbourke.net/dataformats/ply/
***Note from Migration:*** Original Title was: Option to use @Value(AttributeName) in the AttributeRenamer for New Attribute Names Add the option to use @Value(AttributeName) in the AttributeRenamer for new attribute names.
Add .ods reader and writer (LibreOffice OR OpenOffice) !
Level up to the parquet format (updates and snapshot)
When using a FME Server App which fails for some reason there is no built in way to return an error message to the user. It is always an unknown problem.It would be great if there was a way to return a few more details to the user. This is particularly important when an invalid dataset is uploaded. Without a workaround there is currently no way to let the user know their data needs to be fixed.
re-proposing the past idea:
Hi there,In the list of FME Flow repositories, it would be great if you could select one or many and it would download all workspaces together in a zip file.Thanks,Marc
It would be helpful if FME Flow recorded the name of the user who last updated/uploaded a connection (database or web connection) and the date/time that the update took place. If there is an issue with a connection, it is not possible to see if it was recently changed or who the last uploader was so I could check their permissions on the relevant site. For example, an AGOL web connection recently stopped working in FME Flow. When I uploaded my Form AGOL connection to replace it, the issue was resolved, but there is not enough information to explain what happened. I’m not sure whether there was a set timeout for that connection, whether someone with fewer permissions had replaced it, or whether something else had gone wrong.
ProblemCurrently all published parameters are designed to be exposed to users when workspaces are deployed through Workspace Apps. And when I add a parameter for admins and publish the workspace again for existing apps, the new parameter is shown in workspace apps by default, needing to uncheck ‘show in app’ for each corresponding app. In many cases, authors require parameters that:Need configuration per app Must remain editable by Flow administrators Should not be exposed to end usersThis creates a conflict between deployment configuration and user-facing input.Proposed EnhancementAdd a property on published parameters in Workbench such as:Visible in Flow Apps:☑ Yes☐ NoorParameter Scope:- User Input- Administrator ConfigurationExample Use CaseA workspace contains:End-user parameters (file uploads, project selection, dates) Administrative parameters (resource paths, API endpoints, queue names, environment settings)Administrators need to configure the latter when creating Workspace Apps, but end users should never see or modify them.BenefitsCleaner user interfaces Improved security Better separation between configuration and input Reduced risk of user error Faster Workspace App deploymentExpected BehaviourThe parameter remains:Published Available during deployment and app configuration Available through automation and API executionBut is hidden from Workspace App end users.
ProblemOrganizations frequently consume APIs that impose request limits. Currently rate limiting must be implemented manually in individual workspaces.When multiple:HTTPSCallers Workspaces Jobs Enginesaccess the same API simultaneously, the combined traffic may exceed API limits and trigger throttling responses.Proposed EnhancementIntroduce configurable rate limiting at one or more levels: Workspace Level Limit requests generated by a specific workspace. Connection Level Limit requests for all requests using a particular Web Connection. Flow Instance Level Global rate limiting across all jobs and engines. Potential configuration examples:100 requests/minute 10 requests/second Burst allowanceExample Use CaseSeveral scheduled workspaces consume the same business-critical REST API. Each workspace individually remains within limits, but the combined execution volume exceeds the provider's threshold, causing failures and retries.BenefitsReduced API throttling Improved reliability Simpler workspace design Better enterprise API governanceAdditional NoteSome APIs return HTTP 429 (Too Many Requests), but many APIs either implement custom throttling behaviour or provide limited feedback. Centralized rate limiting in Flow would protect these integrations proactively.
In-depth courses for all FME skill levels.
Explore our extensive collection of how-to guides and tutorials.
Log an issue with us. Our support team is ready to help.
