App Improvement Ideas

We are using the Easybill integration in Make to automate the creation and delivery of quotations and invoices. Currently, the Easybill „Create a document“ module does not provide an option to specify the desired invoice format. As a result, documents are created in the standard PDF format. For our use case, we need to create E-Rechnungen, specifically in formats such as ZUGFeRD/Factur-X or XRechnung. Easybill Support informed us that the available fields and options in the Make modules are determined by the Make integration and recommended that we contact Make regarding this limitation. Could you please add the relevant Easybill fields/options to the „Create a document“ → Invoices module, especially an option to define the desired invoice format? Ideally, the module should allow us to select or specify the required format, for example: PDF, ZUGFeRD en16931, ZUGFeRD extended, XRechnung This would allow us to create and send E-Rechnungen directly through Make without having to use the generic „Make an API Call“ module. Current workaround I also tried to create the invoice through the Easybill REST API using Make's „Make an API Call“ module. However, I encountered an issue when assigning the customer. When using the customer's Easybill Customer ID, the API call does not populate the recipient/customer information and returns the error: „Bitte Kunden auswählen“ Interestingly, the native Easybill modules in Make can successfully retrieve the customer's data (name, address, etc.) using the same customer information. Therefore, it would be very helpful if the required API fields for creating an E-Rechnung could either be exposed directly in the „Create a document“ module or if the correct API structure for the customer assignment and E-Rechnung format could be documented. Could you please check whether the „Create a document“ module can be extended to support the required E-Rechnung parameters?

Please add the option “Use column headers as IDs of the columns” to the Google Sheets Search Rows module, similar to the functionality already available in modules such as Add a Row and Update a Row. Currently, Search Rows appears to identify its output fields based on their column positions. This makes existing scenarios very fragile when the structure of a Google Sheet changes. For example, I had an existing sheet with: Column A: Group date Column B: Email Column C: Name etc. Several Make scenarios used the output of Search Rows. I then inserted a new column at the beginning of the Google Sheet. After rebuilding Search Rows, the module correctly recognized the new structure. However, existing downstream mappings were no longer reliable. For example, a field that had previously mapped the participant's email address could suddenly point to the group date instead. This is particularly dangerous because the scenario does not necessarily fail with an error. It can continue running with incorrectly mapped data. In a scenario that automatically creates invoices and sends emails, this can potentially result in emails being sent using incorrect data. The existing “Use column headers as IDs of the columns” functionality would solve this problem. Ideally, Search Rows should use the header name as a stable field ID, so that a mapping such as: Email continues to refer to the Email column even if another column is inserted before it and Email moves from column B to column C. This should allow users to: insert new columns anywhere in a Google Sheet reorder existing columns remove unrelated columns without breaking existing downstream mappings, as long as the mapped column headers themselves are not renamed. This would make Google Sheets automations considerably safer and more maintainable, especially for larger Make setups with many scenarios relying on the same spreadsheet. Expected behavior When “Use column headers as IDs” is enabled in Search Rows, existing mappings should remain connected to the same column header regardless of changes to the physical column position. Current behavior Changing the column structure can change the output field positions of Search Rows and consequently cause existing downstream mappings to reference incorrect columns.

Having a simple way to search inside a data store. At the moment, I have to manually skim through hundreds of records loading them 20 at a time. Keywords: Data store, Filters, Search View: View specific columns

When in dark mode, when modules are associated with a bright color, change the text to a black or dark color. In this instance, its hard to read white text on a yellow background. See attachment.

Please add "Uni Uni" as an available carrier in the Company field of the Shopify "Create a Fulfillment" module. Currently, when "Uni Uni" is mapped to the Company field, the module returns the following validation error: "Prohibited value in parameter 'company'." However, Uni Uni is already supported by Shopify. When retrieving an existing Shopify fulfillment through Make, the Company field is correctly returned as "Uni Uni", and Shopify also generates the Uni Uni tracking URL automatically. This means Shopify already recognizes Uni Uni as a valid tracking company, but the carrier list/validation in Make's "Create a Fulfillment" module does not include it. Please update the Company field in the Create a Fulfillment module to support "Uni Uni". Currently, we have to use a direct Shopify API request as a workaround.

When updating a row in Google Sheets, we get to target columns based on a letter, while the module displays the current corresponding header. The first cell's value in a column stands as the header, but I suppose it's only shown for convenience/readability when setting up the module. This header won't get updated until clicking refresh. Unfortunately, if a column is added later on to that Sheet, then the data will still be sent to the original column... number. In other word, if some data is set to be sent to column C, if later someone adds a column before C (included), then the data will be sent to the newly third column, instead of sticking to the one where it used to go. And so will it be for the following colums. As a consequence, the process gets compromised, and the data go to the wrong columns, until we realize something's wrong. Best thing would be to monitor columns adds and deletions, but I understand it's probably difficult for the Make process to get informed when a column is added. However, I suppose it's possible to feel data based on the header, rather that column number/letter. I feel it'd be much more consistant for users to work that way. Or maybe should this be a setting? I hope my request makes sense. Feel free asking should you need clarification. Thanks

Missive have updated their API for the draft endpoint to allow a boolean for add_default_signature . Would love to see this in the "Create a Draft" module.

Please add an option to reprocess queue records without having to toggle the active switch from Active to Inactive and back. The scenario occasionally have time out errors that cause an interruption in processing and they stop. In these cases there isn't necessarily an issue and they scenario just needs to process again. I'd like an option to just push the records through rather than having to toggle a scenario from active to inactive and back which is just clunky.

Tiktok mobile app has many more options like music, graphic that aren't available through api calls. Support buffers option to do notification posting via buffers mobile app. There is one simple toggle that could be added to buffer app that changes this field: schedulingType is a required field on the createPost mutation, and notification is one of its two valid values (the other is automatic ). Calling the API (or Zapier or Make) directly sidesteps that, because you're specifying schedulingType on each post instead of leaning on the default. The SchedulingType enum is documented in the API reference here: https://developers.buffer.com/reference.html And here's the notification publishing article again for the mobile app setup steps: https://support.buffer.com/article/658-using-notification-publishing

Body: Hi Make team, About the product: Krisp provides AI-powered meeting transcription, summaries, action items, recordings, meeting notes, and insights for calls and online meetings. Suggested integration capabilities: Watch new meeting completed Watch new transcript available Watch new summary/action items generated Retrieve meeting transcript Retrieve AI summary Retrieve action items Retrieve meeting metadata (participants, duration, title, platform) Download meeting recording Search/list meetings Upload transcript or note Generic “Make an API Call” module Potential automation use cases: Send meeting summaries to Slack, Teams, or email Create tasks in ClickUp, Asana, Monday, Jira, or Trello from action items Save transcripts to Notion, Google Docs, Airtable, or Confluence Push summaries into CRMs like HubSpot or Salesforce Trigger follow-up workflows after meetings Archive recordings/transcripts in Google Drive or Dropbox Feed meeting summaries into AI workflows Why this would help: AI meeting assistants are becoming a core business workflow category, and Krisp is widely used for notes and transcription across Zoom, Google Meet, Teams, and other platforms. A native Make integration would significantly improve workflow automation for meeting operations, customer success, sales, recruiting, and internal collaboration. Additional notes: KrispCall already exists as a separate integration, but this request is specifically for the Krisp AI meeting note-taking product. If Krisp already has API/webhook support, adding a generic connector plus triggers/actions would already be extremely valuable. Thanks for considering this integration request!