Open ideas have been reviewed by our Product Management and are open for commenting and voting.
If you are creating the Request URL dynamically, it would be helpful to have the computed URL as one of the attributes in the Output and Rejected ports… particularly the latter port so that you can include it in any error messages you may construct.
According to safe: Tthe user parameters behave a little bit differently inside a custom transformer. They are in fact prefixed with the name of the custom transformer to avoid collisions with the main workspace parameters. Example: if you have a custom transformer called "custtransf" with a published parameter called "custparam", you will have to refer to it like this.value = FME_MacroValues["custtransf_custparam"] The issue is that a user can change the name of the custom transformer in the main canvas, or could have multiple copies ("custtransd_2") and the reference breaks. Ideally I would like to just refer to the user parameter without prefixing anything, and have FME figure it out when interpreting the python. If that's not possible, then having the ability to insert a "transformer name" into the python call would also work. value = FME_MacroValues[transformerName + "_custparam"]
The ArcGIS Online Connector is a great tool for simple and bulk data workflows for ESRI portals (AGOL and AGE). It covers many workflows from bulk actions, data maintenance, metadata and item detail maintenenace, but there are workflows that are limited to using the HTTPCaller and the rest of ArcGIS Rest APIs.Use Cases:Complex migration and portal Backup workflows that require both ArcGISOnline Connector and the HTTPCaller transformers to complete. Mutiple step up portal migrations (dev-stg-prod) or moving items from one portal to another (e.g. ENT to AGOL) To help simplify these complex workflows getting the format parameters like Org URL from an Action Item that calls self/ is valuable. If we have this capability a user can parameterize the Web connection to run multiple portal Org accounts whether its AGOL or AGE.If I parameterize Use case a above, my User parameter dialog would look like below. The top drop down for my HTTPCaller and the bottom one for my ArcGISOnline Connector. While the ArcGISOnline Connector returns this org URL as a format parameter, I need to run an Action Item like List, Upload to expose this. Here’s the reference to self:https://developers.arcgis.com/rest/users-groups-and-items/portal-self/
This was actually raised by @ctredinnick and I think it makes a lot of sense.The FME log files in both Flow and Form are great for finding out what went on with a process. But wouldn’t it be great if you could load the Log file into Form against the same workspace and see the numbers coming from each port. Visually, it could help pinpoint issues in the flow of features quickly, subsequent to the run, and would be especially useful for Flow logs.
It would be great to have an option to add one more input port to this transformer.In some scenarios, it's useful to differentiate between two input datasets—so that the transformer can overlay one dataset against the other, without comparing a dataset against itself.
Would more users like to see an option or prefer if the feature information window sorted exposed attributes in alphabetical order? Currently, the attributes are sorted by table order.
FME Workbench does not always prompt the user when an embedded transformer was updated in its fmx file. It would be useful to have an option to update embedded transformers manually. Maybe in a similar fashion as default transformers can be upgraded. How about right-click -> update to latest version -> bring up a dialogue to select the fmx file? I am aware that this is not required for linked transformers but in some cases it is more practical to use embedded transformers. Also see here.
I would like the option to view the entire job log on flow instead of have to click through pages using the navigation buttons on the job summary page
I would like to write out a DGN Microstation file and be able to set the display setting, so that when I open my data it will be displayed as zoomed to fit.Ideally, I would like to do this dynamically as I use a fanout of different areas to multiple Microstation DGN files. This would allow the DGN files to open with the view focused on the data in the area.
In my experience, web service credentials and the base url for a web service go hand in hand. For example, if I have credentials for a sandbox instance of a service, that would go along with a sandbox base url (ex. https://sandbox.servicename/api/v2 or https://servicename/sandbox/api/v2 )But I have found that the pre-built web services do not prompt for a base url.I realize that I can add a prompt by creating my own Web Service, but how would I access my Base Url parameter within the Request URL in the HTTPCaller?My idea is:Prompt for endpoint base url by default in all Web Services (to be entered while creating a new Web Connection). In the HttpCaller transform, rename the “Use Authentication” checkbox to “Use Authentication / Web Connection” In HttpCaller, move Request Url below the checkbox If there is a non-empty endpoint base url defined in the selected Web Connection, Add a “« base url” marker into the Request Url textbox The user can then complete the endpoint (i.e. /employees )The benefit of this feature is that I can have multiple workspaces all using the same Web Connection, and if either the URL or the credentials change, I can modify this once in FME Flow without having to alter any workspaces in FME Form.
Hi there,I would like to be able to right click on my web connections in the navigator and reauthenticate, rather than having to go into the FME Option menu.E.g.
I would like the version of a custom transformer to be available as a parameter in FME so that it could be logged out for debugging purposes.This is helpful in the case there are many versions of a custom transformer.
It would be very nice to extract the DWG properties (the equivalent of the DWGPROPS command in AutoCAD) into FME. These are drawing properties and not feature properties.
***Note from Migration:*** Original Title was: When renaming an attribute, have the name-change propagate through the subsequent transformers automatically Often I find myself in need of renaming an attribute after I've built out complex transformations. If doing so towards the beginning of the workflow, there's the ripple-effect caused by breaking the subsequent transformers containing the renamed attribute, and it can be tedious to make the corrections in the downstream transformers. It would be super useful to have an option for auto-applying the rename downstream from the rename action.
A way to update downstream attributes following attribute renaming would be a really nice feature. It is already done for parameters so why not put in the work to extent it to attributes as well.For example a user has workspace which includes several attributes which are coming from a JSONFlattner - after creating several transformers downstream using the newly created attributes the user decides that he wants to add a prefix to the attributes. When adding this prefix the rest of the workspace breaks because none of the references have been updated to reflect the changes. Probably the more common situation is when an input data set gets an updated schema - e.g., Maybe “Layer” becomes “layerName”. If I update my reader then the rest of my workspace will break. At this point the author has two choices, either, rename all the attributes in the process to match the new names (probably good practice) or just add one AttibuteRenamer at the start of the process to rename the new names back to the old names so the workspace runs again. There are quite a few situations where I think having this kind of functionality would do a lot to improve workspaces readability with little effort on the authors part. For example often when building a workspace it’s pretty common to just reuse the out-out-the box default attribute names (e.g., _area). Then once you’ve finished the bulk of the work maybe you see that it’s unclear what “_area” actually is so you want to rename it so something like foorprint_area - only to find our you’ve used it in several places. Perhaps you decide you can’t be bothered to rename it.This kind of functionally can be used to help promote better readability and better practice with attribute naming. It would also make it a lot easier for AI to understand sections of workspaces as well - (footprint_area x building_height) is a lot easier for an AI to understand what is happening with some context. The way I see it happening would be either completely automatic (similar to User Parameters) or a prompt with a list of affected transformers and which ones to update.
Make it easier and faster to convert raster images to vector polygons.Improve performance of RasterToPolygonCoercer and add more options for customizing the transformation.FMEers, we are interested in knowing how important raster-to-vector conversion is to you. Please upvote if this is an operation you require, and comment to let us know what specifically you'd like to see. Any details you can provide on your use cases would be helpful.
SQL database in Microsoft Fabric is now in preview, we would like to be able to read/write to it with FME. Only Microsoft Entra Auth is supported - https://learn.microsoft.com/en-us/fabric/database/sql/connectPlease can the sql server readers/writers be updated to support this type of authentication.
Has FME ever thought about going into the business of creating web or desktop applications? This might be out of the FME comfort zone, but I thought I’d ask the question. Thanks!
***Note from Migration:*** Original Title was: Add the Ability to Generate Documentation (PDF, Word, Sharepoint, Web) from Workspaces I don't know if you are familiar with BizAGI (http://www.bizagi.com/). It's a tool to document "processes". After you described the tasks etc in the process you can generate documentation (PDF, Word, Sharepoint, Web, etc).I think it would be cool if it was possible to document FME Workspaces in a similar way. If it would be possible to write descriptions in the "transformers", bookmarks could be used to generate structure, different "chapters" in the documentation (in a PDF).Now I am sometimes using BizAgi to document FME Workspaces. Because FME Workspaces are very "process oriented" it would be nice to be able to generate documentation automatically. It would also force you be able to write even more "clean" workspaces :).
Hi.Would it be possible to add a simple yes/no (default: no) option to the "Workspace Parameters/Logging" that enables "versioned" log files ?It might be implemented simply by having FME append a timestamp (e.g. start of run) to the log file name (whatever that may be), so no previous log file is ever overwritten.The purpose is to enable checking log files from multiple runs against each other. Some times a translation is run multiple times before a comparison is warranted.The option to "append to log" file doesn't really work for this, and is a lot more complex to handle and administrate.Cheers
I would like to see the option added to log a 'SUCCESS' message. Next to the INFORM, WARN and ERROR messages, it would be helpful to filter LOG messages to see what is executed succesfully. There is a big difference between inform messages and SUCCESS messages. This would also allow for another use of the Logger transformer.
Make FME a supported true curve client, thus enabling better support for ESRI Utility Network.ESRI ArcGIS Portal Feature Services have a configuration setting to allow true curve updates by true curve clients only - this needs to be on/live to support features and analysis in Utility Network.FME Feature Service writer is not a supported client, so updates to curves fail/are not permitted - limiting FMEs capability to support UN.
FME Server has a good range of Rest api calls but they aren't all documented. For instance, named connections are avaliable by fmerest/v3/namedconnections/webservices, version control push by /fmerest/v3/versioncontrol/remote/push. It would be great if more of these calls could be documented
EDIT: it appears that this issue was related to a specific workspace and not to FME 2025 in general. I have seen this behaviour on several occasions but am unable to reliably reproduce it. If I am able to find a way to reproduce it in the future I may open a support ticket.I’ll leave this post up in case other people run into this and are able to add more context… --- please ignore ---The quick add functionality in Workbench is a huge timesaver. It used to work for camel-case searching with just 2 characters but now (FME 2025) requires at least 3 characters before returning results.As the majority of transformers are one or two word concatenations this is a huge step backwards.I’ve become so used to just typing 2 characters abbreviations to add a transformer to the canvas and now that capability has been taken away it will reduce my productivity when building workspaces.As an example, typing “fm” used to bring up the FeatureMerger but now it brings back 0 results.“ac” used to bring up AttributeCreator, now it brings back 0 results.
Just having a Trigger that gets a notification when a Workspace App is run.I know perfectly this is possible through an FMEFlowNotifier and a Topic trigger or alternatively an HTTPCaller and a Webhook trigger, I just don’t find it intuitive enough. I recently got a couple of users asking me this very same question and I think this could be done much easier. Besides, right now you have to maintain your notification system in 3 different places: the workspace, the topic and the automation.There’s already some questions in the community about this, which I think it shows it’s not that easy:And no, an Automation App is not the same because it can’t be used together with a data streaming or data download service.
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.
