I know there are paid alternatives like Order Printer Pro, but Shopify really should add the ability to print from Draft Orders to their in-house Shopify Order Printer app. Every time merchants install a 3rd party app, we are opening attack vectors into our stores. If an app developer or an API key gets compromised, bad things can happen. The aforementioned app requires customer and order write permissions, so you can imagine the risk involved. Many app developers aren’t even in the same country as merchants, so recourse when these situations arise is limited.
We tried using Sidekick to re-implement Shopify’s Order Printer Pro. It was super promising and we were able to get it looking just the way we wanted. It worked with Orders and Drafts. However, due to the “sandbox” used for Sidekick apps, the apps cannot print, nor can they add shortcuts to the “More Actions” dropdown on the Orders view, or Order screen.
The simplest solution is for Shopify to update their Order Printer app to work with Draft Orders. I already made the feature request through Shopify Plus Support. They acknowledged and logged the request, then suggested posting to the community forums so people could “upvote” the feature request. So that’s what I’m doing.
I think this is a reasonable feature request. If Shopify’s official Order Printer already supports standard orders, extending that support to Draft Orders would remove the need for many merchants to install a third party app for what is essentially a core workflow.
Beyond the security considerations you mentioned, there’s also the benefit of reduced maintenance and greater reliability. Relying on a built in solution means merchants don’t have to worry about app compatibility, subscription costs, permission changes, or long term support for such a fundamental feature.
For businesses that regularly create Draft Orders, having a native print option directly within Shopify would provide a more consistent and streamlined experience without adding another dependency to their store.
If this helped answer your question, please mark it as the solution so it can help others facing the same feature request.
Worth sharpening the feature request, because the blocker sits one level below the Order Printer app.
Printing in the admin now runs on print action extensions, and those targets only exist in four places. admin.order-details.print-action.render, admin.order-index.selection-print-action.render, and the two product equivalents. There is no draft order print target at all. So Shopify’s own Order Printer cannot be pointed at drafts even if the team wanted to ship it this week, they would have to add the target first. Filing the request that way is stronger, because a new target unblocks every print app at once instead of only the first party one.
On the third party risk, the scopes are checkable before you install. A print action reads, it does not write. read_orders covers it, read_all_orders is only needed for anything older than 60 days, and reading drafts is read_draft_orders. Nothing about rendering a document needs write_orders or write_customers, so if an app asks for those to print, that is a fair question to put to the developer in writing before you grant it.
The middle path that does exist today is admin.draft-order-details.action.render. That target is live, it puts an entry in More actions on the draft order page, and a custom app you build for your own store never leaves your org, so the compromised developer scenario goes away entirely. You lose the Print menu placement but you get a button in the right place.
Did Plus Support log the request against Order Printer, or against the missing extension target? Those are two different backlogs and only the second one helps the rest of us.
I’m assuming they logged the request against Order Printer. Regarding the 3rd party risk, I’m not sure what you mean by the scopes being checkable. To me, it looks like a take it or leave it…
I’m a bit confused by your statements on the print targets. You mention that there is no draft order print target, but then go on to describe how to accomplish it using the ‘admin.draft-order-details.action.render’. “Shopify cannot be pointed at drafts even if the team wanted to ship it this week”, yet somehow ‘Order Printer Pro’ was able to accomplish it. Maybe I’m not understanding something?
Fair hit on the scopes, I said that badly. The install screen is take it or leave it, you cannot uncheck anything, and there is no negotiating at that dialog. What I meant is you can read the list before you ever reach that screen. The App Store listing has a Data access section further down the page, and for Order Printer Pro it spells out Edit customers and Edit orders, plus sensitive customer data meaning name, email, phone and physical address. So the real decision point is the listing page, not the grant screen. Which does not help much when the answer is still these are the scopes and that is that, agreed.
One thing sits under it though. Anything touching customer name, email, phone or address counts as Level 2 protected customer data, and a public app has to be approved for those fields individually and commit to encryption at rest and in backups, separated environments, access logs and an incident response policy. That is not a shield against a compromised developer. It does mean an app holding your customer data has signed obligations rather than nothing. Also relevant to your Sidekick attempt, custom apps get protected customer data access automatically, so building your own does not hit that wall.
On the print targets, the confusion is mine for squashing two different menus into one sentence. The Print menu is its own extension surface and it has exactly four targets, order details, order index selection, product details, product index selection. No draft order one. More actions is a separate surface and drafts do have targets there, admin.draft-order-details.action.render plus the index equivalents. Since there is no draft print target at all, Order Printer Pro can only be reaching drafts through that second surface, so the Print you click on a draft is their own label inside their own action rather than the native Print menu. The other difference is who renders. A print action hands Shopify a src and Shopify shows the preview and the browser prints it. An action extension opens the app UI and the app prints for itself.
Which means my even if they wanted to ship it this week was too strong, and you were right to push. Shopify could ship draft printing as an action extension tomorrow with nothing new on the platform, they would just land in More actions like everyone else. Adding the print target is the version where it lands in the menu you actually expect and every print app gets it at once. If Plus Support logged this against Order Printer the app, that is the one that quietly ships as an action. Worth adding a line naming the draft order print action target if you want the second outcome.
