Shape the future of FME with your ideas
Open ideas have been reviewed by our Product Management and are open for commenting and voting.
It would be useful to have a built-in way to classify workspaces according to both their operational priority and the type of impact they have.These are two separate but related properties:Priority Priority 1 – High Priority 2 – Medium Priority 3 – Low The priority would indicate how important the workspace is and how quickly it needs attention if it fails.Impact classificationA workspace could also have one or more impact classifications, for example: Business-critical process System or infrastructure-critical Integration with other systems Data production or distribution Public or external service Internal supporting process Personal workspace Development or testing Multiple classifications should ideally be allowed. For example, a workspace could support a business-critical process while also integrating with several external systems.From a system administration perspective, this information would be particularly helpful during: FME Form and Flow upgrades Maintenance and planned downtime Incident response and troubleshooting Workspace testing and validation Dependency analysis Documentation and system inventories Ideally, the priority and impact classifications could: Be assigned to a workspace in FME Form. Be included when publishing the workspace to FME Flow. Be viewed and modified from the FME Flow Web UI. Be searchable and filterable in FME Flow. Be retained when republishing or migrating a workspace. Be available through the FME Flow REST API. REST API access would make it possible to include this information in monitoring dashboards, workspace inventories and automated upgrade assessments.For example, before an upgrade, administrators could identify all Priority 1 workspaces that support business-critical processes or have integrations with other systems. These workspaces could then be prioritized for testing before and immediately after the upgrade.This could be implemented using dedicated workspace metadata fields or through a standardized tagging and classification system. Dedicated fields would likely make the information more consistent and easier to manage across an organization.
When downloading data using Data Download service (e.g. from an FME Workspace App), a Zip file is created containing the output files. The zip file is automatically named something that looks like “FME_4B425D3A_1772473610895_13172.zip”. It would be nice if an option was implemented to allow customizing that name to something that is more user friendly. For example allow authors to specify what exact name the Zip file should have, or allow the use of parameters to create a string to use as file name. Even if the final filename has to have some extra characters at the end like 4B425D3A_1772473610895_13172, giving authors some customization capability would be beneficial.
In the Autodesk AutoCAD DWG/DXF-writer (and in the other DWG writers too) it would be good if you could choose an attribute for Layer Description, Default Linetype, Default Color and the states: On, Frozen, Hidden, Locked, Plottable. It's not so usable right now when you need to hard code these values which makes all layers look the same.
When working with a datasets that have a large number of attributes, it would be great to have some enhanced selecting/filtering in the Reader/Writer Attributes tab. For example, starts with, ends with, contains, other tests - like contains x but does not start with y. Regex support would be good, but something like a Tester merged into the R/W could also work. Thanks.
Many of the FME Academy examples use the City of Vancouver Open Data portal datasets, including Property Parcel Polygons, Addresses, Zoning, Parks, and Street Trees.These datasets are not generally hosted in ArcGIS Online by Safe Software, but they are available through the City of Vancouver Open Data APIs and can be consumed directly in FME.Home — City of Vancouver Open Data Portal and parcels exampleFME user can download these publicly available datasets SHPs, GDBs etc from github unpacking them to C:\FMEData\Data which the training workspaces reference.I would like to suggest either:Making the commonly used FME training datasets available as ArcGIS Online hosted feature layers (should their license allow Safe to ETL them to AGOL), and/or Publishing an article demonstrating how to consume the Vancouver Open Data datasets directly from ArcGIS Online using: ArcGISFeatureService Reader (safe.esri.agol) package ArcGIS Online Connector Other ArcGIS-related readers and transformers where appropriate
The AutodeskDocsConnector currently requires a file URN. This is contained within the URL used by ACC, but in encoded form. It would be helpful if you could also just paste the ACC URL directly into the connector and have FME do the parsing internally.
It would be helpful if the List option could include basic file properties, such as the last modified date, name of the person who modified it, etc.Additionally, it would be helpful if the Download option could also include attributes showing the original name, URL, URN, last modified date, name of the person who modified the file, etc.
From this question: Toolbar connections are stored separately to Web Connections. When you change to using FME Flow as your Web Connection storage you can’t separately manage your toolbar connections.I wonder if an approach could be that the toolbar connections are their own separate ‘connection type’ that shows regardless of you connection storage settings? Additionally this could then give you the option to copy to/from the toolbar and connection storage
A great enhancement would be to allow AWS connectors to use IAM roles that have already been granted to the EC2 that the engine is running on to the various AWS resources in AWS.Security is changing where the use of keys to deemed not acceptable anymore.
My ideal scenario would be the ability to register an individual FME Flow App as a Microsoft Entra ID application.When a Flow App is intended only for internal use, the app could require users to sign in with their Microsoft 365 account before they can access it. Authentication and access could then be controlled through Microsoft Entra ID, including:Microsoft 365 sign-in Multifactor authentication Conditional Access policies Assigned users or Entra ID groups Application roles or group-based permissions Centralized access revocation and audit loggingMost importantly, users who only need to run a Flow App would not need to be created or provisioned as FME Flow users. FME Flow administrators and workspace authors could continue using regular FME Flow accounts, while end users would authenticate directly to the specific Flow App through Entra ID.A typical workflow could be:An administrator registers the FME Flow App in Microsoft Entra ID. The administrator assigns permitted users or groups to the application. A user opens the Flow App URL. If the user is not already signed in, the app redirects them to Microsoft sign-in. After successful authentication, the user can access the Flow App without having an FME Flow account.This would create a clear separation between:FME Flow administrators and authors, who require FME Flow accounts; and Flow App consumers, who only need permission to use a specific application.It would make internal FME Flow Apps much easier to secure, govern, and deploy. It would also allow organizations to publish separate public and internal Flow Apps while using their existing Microsoft 365 identity and security controls for internal access.
This idea is a follow up on an earlier question I posted on the FME Community: How to use/access the parameter of an FME Flow Network Based Resource in FME Form? | CommunityAt that time Deployment Parameters did not yet exist in FME Flow. Now they do, it seems that this could be very close to the idea Laura suggested in the above question;I like the idea of being able to directly import the list of Resource parameters directly from FME Flow into FME Form. That's worth posting as an idea. The idea I now see is that it would be great if Resource parameters (the ones that one can create in the 'Resources’ menu item of FME Flow), could also become available as deployment parameters. That is because deployment parameters behave exactly as I would like for my usecase; I can import them from FME Flow into FME Form, and when authoring in FME Form I can also use a local value for these parameters.
The trigger would leverage Microsoft Graph Change Notifications (webhook subscriptions) to allow FME Flow Automations to react to events from Microsoft 365 services in real time.Instead of polling:FME Schedule ↓Check SharePoint ↓Compare timestamps ↓Run workspace FME would receive notifications directly:SharePoint ↓Microsoft Graph Change Notification ↓FME Flow Trigger ↓WorkspaceThe trigger could support:•SharePoint Online Document Libraries•OneDrive for Business•Microsoft Teams Files•Microsoft Liststhrough the same Microsoft Graph API subscription mechanism. Microsoft Graph already provides a standardized Change Notification framework allowing applications to subscribe to changes in Microsoft 365 resources. These notifications can be generated whenever files, folders, list items, drives, teams, users, and many other entities change. Benefits1. True Event-Driven ArchitectureNo scheduled polling.Automations only execute when something has actually changed.2. Reduced Load on FME FlowCurrent polling patterns require:•Scheduled Automation runs•SharePoint authentication•Metadata retrieval•Change detection logicEven when no files have changed.Graph notifications eliminate this overhead.3. Reduced Azure DependencyNow i need to use power automate or azure functions for thisA native Graph trigger would remove middleware and simplify deployments. Community recommendations today largely revolve around SharePoint webhooks or polling because no native trigger exists. 4. SecurityCustomers would no longer need to:•expose FME Webhooks publicly,•build custom webhook listeners,•maintain Azure Functions solely for event forwarding.FME could directly manage Graph subscriptions and renewals.
Add more validation types and/or improve repair & diagnostics (tell us in the comments what you'd like)
Due to the way decimals get stored one dataset may, for example, contain 1.7 and another 1.700000003. I can tell by looking that they’re the same as the data has no more than 4 decimal places. It would be nice if the ChangeDetector had a tolerance for numbers. If I used 0.00001 for the above, as the difference between them is less than that, it would treat the data as unchanged.
Migration Note: Idea originally posted on 2016-04-20
Possibility of including images inside Annotation . Is better when we want to document our Workspace with images.
It would be helpful to have a transformer designed to clean common data problems (selectable from a set) and handle them in standardized ways, such that workspaces would be less likely to fail.This can be, and surely is frequently, done easily with a chain of existing transformers. But the problem of data with hidden or obvious problems being ingested is pervasive.In one use case, I have a workspace packaged up as an app on FME Flow. It accepts input from a few fields in the app or as an Excel file. There are more often breaking errors in what users enter than not.In another, metadata is read in from one source and applied to another, working with XML and esri file geodatabase formats. At different times, characters contained in the metadata have broken the workflow completely.Suggestions include:Trimming leading and trailing spaces Removing line breaks Converting or removing specified or all unicode characters (e.g. nbsp) Escaping or replacing special and/or other problem characters (e.g. `, ‘)By wrapping a functions to sanitize, replace, and trim data, especially with what are common and often hidden problems, in a single and easy to use transformer, would help to get many workflows off to a better start.There are probably other characters and faults that I’m not thinking of - a new day, a new data hiccup!
The setting recalculates the Initial Extent and Full Extent of the Feature Service, making the results a lot better than the current behavior. This setting is available in the soon to be deprecated ARCGISONLINEFEATURES format writer.
If the information product you want to manage is a hosted feature layer view then at present you need to manually adjust its properties outside your ETL workspace, or tackle the job using the ArcGIS REST API via HTTP.Feature service views offer ways to leverage feature services other than simply as they were created.Here is an example of using HTTP calls to automate one property - swapping the source service for the primary layer..In addition to basic create views, add and remove layers, and delete views functionality for views you might want to adjust name, description, tags, visibility, extent, editing access, definition query, field visibility or layer order.The definition-adjusting REST calls (addToDefinition, deleteFromDefinition, updateDefinition are tricky to implement.Who would like this capability?If you have other requirements comment in this idea.
A parameter is like an argument that is static. A variable, however, represents a state and can be dynamically created and assigned in a workspace. I wish FME workspace UI exposes variables the same way it exposes parameters or attributes. Converting variables to attributes via VariableRetriever does not help, as attributes are about content while variables are about states and flow control.I am in agreement with @bambography in his or her post. https://knowledge.safe.com/questions/34563/can-global-variables-be-accessed-as-values-in-tran.html
Allow the XMLUpdater to accept some sort of table (ex. text file, or .csv) as input for the ‘Updates’ parameter. Currently, the ‘Updates’ section must be entered manually. There is no way to import rows in bulk.I am currently working on a workbench to update file geodatabase metadata. The default format has well over 100 metadata fields! Usually, for a task like this I’d make an input table Parameters and feed that in to the tool - in this case it would be for the parameters in the Updates section: Update Type, XML Path, Value Type, and Value.I did a search through this forum for ‘XMLUpdater’, and found many results related to updating metadata of one kind or another. It seems to be that this improvement would be helpful for anyone looking to update metadata or complex (but well structured) XML.I suppose another option would be to allow ‘Create User Parameter’ from the ‘Updates’ parameter. Then the user could select a file to input, or even copy paste into a text editor formatted commands for this parameter.For now my current solution will be manually keying in my most critical top ten or so updates - but it would be simpler and less work to pull in all from a list in bulk.Thanks for considering this improvement!
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.