Skip to main content

Open ideas have been reviewed by our Product Management and are open for commenting and voting.

Filter by idea status

Filter by product area

4611 Ideas

mcsjo
Contributor
mcsjoContributor

Workspace priority and impact classification in FME Form and FlowNew

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.

rsun
Contributor
rsunContributor

Allow individual FME Flow Apps to use Microsoft Entra ID AuthenticationNew

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.

tva
Contributor
tvaContributor

Microsoft Graph Change Notification TriggerNew

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.