Data integration is the foundation of better decisions, automation, and innovation. It’s also the source of some stubborn day-to-day headaches for data teams. In our recent Ask Me Anything About Data Integration webinar, our technical support team answered questions from the FME Community and the live audience, covering a range of topics from underrated FME features to automation tips and tricks.
What are the most underrated or lesser-known FME features?
Each of our experts weighed in:
- Add Attribute Directly From a Transformer’s Output Port: Instead of dragging in an AttributeCreator or AttributeManager every time you need to tack on a new attribute, just right-click on any output port of a transformer and choose Add Attribute. A small Edit Attribute dialog pops up where you can set the name and value, and the attribute flows downstream from there. It’s a one-click way to keep your canvas tidy and stop your workspaces from ballooning with helper transformers.
- The FME Flow REST API: Many users walk past it because their workflows don’t seem to call for it, or because they assume you need Postman or another external tool to use it. You don’t. From the main FME Flow landing page, you can open the V4 API interface, generate a temporary token for testing, expand any of the endpoint groups (automations, schedules, etc.), click “Try it out”, fill in the parameters, and execute. It’s an incredibly easy way to dip your toe into REST and is one of the best troubleshooting tools you have. When something isn’t behaving in Flow, hitting the relevant endpoint directly gives you a ton of information about what’s going on.
- FME Flow Tags: If you’ve ever built up a collection of schedules, automations, or workspaces in Flow and tried to find one particular thing via the REST API, you know the pain. Tags solve this elegantly: tag your items by project, environment, owner, or whatever taxonomy fits your team, and you can filter by tag both in the UI and through the API. Tags are a huge organizational win once teams adopt them.
- Enable Adjacent Feature Attributes: In transformers like AttributeManager and AttributeCreator, this checkbox lets a feature pull values from the previous and subsequent features in the stream. That means you can build cumulative totals, conditional values that depend on neighbors, or rolling comparisons without resorting to ListBuilders, Counters, and self-joins. It’s easy to overlook because it lives under an “Advanced” expander, but it can collapse multiple steps into a single transformer.
- NoFeaturesTester: This transformer routes features down a NoInput port when nothing arrives, which is very useful for data validation. Pair it with a Terminator to fail loudly when an upstream source returned zero rows, or with the Emailer to send a heads-up to the team. A simple, reliable safety net for any workspace that depends on inputs actually being there.
How to get the schema back into the stream after a FeatureReader produces generic output?
In this scenario, you can see the attributes in the Attribute Viewer but can’t dynamically expose them. What do you do?
First, consider whether you actually need to expose the attributes. If you’re just passing features through and writing them out (dynamic writing), you don’t need to explicitly expose anything, as the schema travels with the features. You only need to expose attributes when you want to manipulate them downstream in the workspace.
If you do need to manipulate them, then yes, exploding the schema and feeding it into Schema-aware transformers is the right shape of solution. Dynamic workflows are situational, and a generic “do these five steps” recipe usually misses the point. The best resource here is our Dynamic Workflows in FME tutorial.
Directory reader, ArcGIS connections, and SSL certificates
Three separate but related pain points:
- Using a FeatureReader on multiple files from a path-names directory reader, then exposing all attributes from that dynamic source. Again, consider that you don’t always need to expose. If the goal is to land the data, dynamic writing handles it. If you need to manipulate specific attributes downstream, that’s where it gets situational.
- Connecting, updating, and writing to enterprise ArcGIS with SSO (Duo, etc.). The red flag here is Duo / MFA on the service account. If the account running FME Form or FME Flow has multi-factor authentication enabled, you’re going to have a bad time — interactive prompts and unattended automation don’t mix. The fix is to run FME under a dedicated service account that does not have MFA enabled.
- Upgrading SSL certificates in FME Flow yourself. Good news: as of FME 2025, you can configure PFX certificates directly in the installer. That removes one of the longest-standing pain points around Flow deployments. Support for additional certificate types is on the roadmap.
Why do the Classic Geodatabase Writer vs. FeatureWriter behave differently with renamed schemas?
When resolving Esri domain values, FME creates _resolved attributes. After using a BulkAttributeRenamer to strip the suffix, the Classic GDB Writer fails on schema validation, but a FeatureWriter set to GDB succeeds. Why?
It comes down to how each writer expects to receive its schema. The FeatureWriter is designed to retrieve the schema from the workflow at runtime, making it more flexible when attributes are renamed or retyped upstream. The Classic GDB Writer, by contrast, often has a schema already baked in from when the writer was added, so if your incoming attributes don’t match the writer’s expected schema (especially their types), validation kicks in and fails.
The fix usually lives in how the GDB Writer is configured. Check whether it’s expecting the original reader schema, whether attribute types match what’s actually flowing in after the rename, and whether you can edit the writer’s schema to match the renamed/retyped attributes. If you’re blocked by behavior that still doesn’t match expectations after that, submit a support ticket, as these can be specific to the writer configuration and need eyes on the workspace.
How do I dynamically update published parameter choices in newer FME?
This is in reference to the Dynamic (but Hacky) Updates to Published Parameter Choices Knowledge Base article. Given that the Feature Types to Read user parameter has gone away, what is the modern equivalent in FME 2025+?
The new answer is dynamic parameters, introduced in 2024 and configurable directly in the FME Flow interface. They solve the original problem (published parameter choices that respond to context) without the hackiness of the older workaround. There’s a dedicated parameter window in the Flow UI for configuring them.
Help with Dynamic workspaces, SchemaScanner, and SchemaMapper?
The Dynamic Workflows in FME tutorial is the best starting point if you want a structured walkthrough.
SchemaScanner has a “read dates” checkbox that catches a lot of people. If it’s unchecked, your date fields won’t be written with date types and will just come through as strings. Make sure it’s configured for the types you actually want.
For dynamic mapping, the SchemaMapper is usually the right tool. It’s purpose-built for table-driven mapping.
How do I dynamically map attributes from source to target using a mapping table?
What is a fully dynamic approach to a data-mapping table defining source/target tables and columns?
This is exactly what SchemaMapper was built for. It reads a mapping table and applies attribute renames, type changes, and value mappings dynamically based on that table — no per-attribute hardcoding. Other transformers like AttributeValueMapper can play a role for specific value-level transformations, but for the table-driven source-to-target column mapping pattern, SchemaMapper is the answer. We have tutorial articles specifically on working with the SchemaMapper that walk through real implementations.
Traffic routing in FME — INTREST (IDF), OpenRouteService, or commercial APIs?
IDF / INTREST format is not currently supported natively in FME. With this format or any other format you’d like to see added, please submit it to the FME Community Ideas page. This is exactly the input our developers look at when prioritizing new formats and integrations.
OpenRouteService works today via the HTTPCaller (to fire the request) and JSONFragmenter (to parse the response). Pretty much any HTTP/JSON routing API can be integrated this way.
For commercial routing services such as Google, TomTom, and HERE, use the same pattern: HTTPCaller plus JSON parsing. There’s also a HERE transformer currently available on FME Hub if you want a more turnkey starting point.
What’s the most important characteristic for building useful workspaces?
Three answers:
- Zoom out. Look at how different teams, departments, and systems use the same data — workspaces designed in isolation tend to age badly.
- Know your data and your business needs. FME is the tool; the solution lives in understanding what needs to be done and where it needs to go.
- Creativity and problem-solving. There are usually a dozen ways to solve any FME problem; getting to a good one means thinking past the first approach that occurs to you.
When should we automate vs. keep things manual?
Automate when a process is repeatable, frequent, slow, or a bottleneck—especially when multiple people touch the same workflow (automation removes a major source of human error). The rule of three is a handy heuristic: if you’ve done the same task three times in a row, it’s probably time to automate. Conversely, if you’re the only person running something and it’s quick, manual can be fine.
Is there a good starter project for FME Flow for someone afraid to make the jump?
Yes. Every FME Flow installation ships with sample workspaces that you can run and explore right out of the gate. Beyond that, pick a project tied to something you’re already interested in. For people coming from a GIS background, the Geometry parameter is a brilliant on-ramp because it’s interactive in a way that nothing in Form really is — you can build genuinely fun data apps with it. Depending on your plan, your sales rep can also set you up with free FME Flow Hosted credits (roughly a month of engine time) so you can experiment without a local install.
What’s the difference between scheduling a job and using an automation triggered by date?
Use a schedule if you’re just running a single workspace on a clock and don’t need error handling or conditional logic — it’s the simplest tool and it’s heavily used for good reason. Use an automation the moment you need to chain workspaces, branch on success/failure, or react to events. The shortcut: single workspace, fire-and-forget → schedule. Anything more sophisticated → automation.
Email notifications for failed or cancelled jobs?
Set up a trigger on your job (failure or cancellation), then wire it to the email action. The procedure is documented in our Knowledge Base — we linked it during the session.
How do I understand the API of an external application I want to integrate with?
Start with the application’s API documentation. In recent FME versions, the OpenAPI Caller transformer lets you import an OpenAPI spec directly, which then exposes all the endpoints inside FME with their parameters already configured — a huge time-saver. And a tip from Evie: live API playgrounds and example requests are often easier to learn from than the documentation itself.
Our daily API calls slow each other down — how should we orchestrate them?
Two strategies:
- Inside a single workspace, you can configure HTTPCallers to be on/off based on context, or insert FeatureHolders between them to serialize the calls so they don’t all hit the remote system at once.
- At the Flow level, set up a queue with a single engine assigned to it. Route all your API-calling jobs to that queue and they’ll stack up and run back-to-back — no orchestration logic needed in your workspaces. This also plays nicely with APIs that have rate limits.
Reach Out: You’re Probably Not the First to Hit This Problem!
You don’t have to sit on a problem alone! Whether it’s a quick “is this normal?” question or a stubborn integration issue, we have lots of resources available.
- Search and post on the FME Community. Safers actively monitor it, and other community members often answer faster than we do.
- Open a support ticket for anything technical that’s blocking you. No question is too small.
- When you can’t find the answer on the Community, posting it helps us find our blind spots — chances are you’re not the only one stuck on it.
Learn More
- Getting Started with FME Form — the foundation tutorial for new users.
- Data Inspection in FME — for getting comfortable with previewing and validating data.
- FME Academy — guided learning paths, including the 90-minute FME Accelerator crash course.
