TL;DR: Automating LinkedIn distribution took a few hours of actual build time and about twice that in decisions. What connector to use, where content lives before it goes out, how to handle LinkedIn’s API quirks without breaking the scenario. This post covers the real setup: the trade-offs, what failed on the first pass, and the things worth knowing before you start.
Most content distribution problems aren’t about writing. The writing happens. The problem is that after writing, you still have to open LinkedIn, paste the text, fix the formatting, and actually hit post. That last step is where consistency dies. Not because posting is hard, but because it’s manual, low-stakes in the moment, and easy to skip.
I’d been documenting operational workflows for clients for long enough to know that any recurring task done manually more than twice a week is worth at least evaluating for automation. LinkedIn posting qualified. So I built a distribution workflow using Make.com. It took an afternoon to get running and about two weeks of small fixes after that.
This post is about what the build actually looked like: the decisions, the things that didn’t work, and what the working version does.
What LinkedIn Actually Lets You Automate
LinkedIn’s API has more restrictions than most people realize before they start. The official Make.com LinkedIn module lets you create shares (text posts and article links) on personal profiles, and it supports company pages if you have admin access. What it doesn’t do: document posts, carousels, video posts, or anything that requires the native editor to format correctly. Those stay manual.
The module authenticates via OAuth 2.0. The access token expires every 60 days, which means you’ll need to reconnect the connection in Make.com every two months or the scenario fails silently. That’s not obvious until it happens.
One thing worth knowing before you start: LinkedIn’s algorithm reportedly treats auto-posted content differently from natively published posts in some accounts, though this varies and LinkedIn has never confirmed an official penalty. Whether that matters depends on your volume and goals. For distribution at low frequency (a few posts a week), the difference in any real reach is negligible. For accounts trying to optimize every post, it’s worth testing.
The First Real Decision: Where Does the Content Live?
Before touching Make.com, you need to decide what it reads from. This is the decision that shapes everything else, and it’s where most people underestimate the friction.
Three options come up most often: a Google Sheet, a Notion database, or Airtable. They’re all workable. The difference is in how you interact with the content before it goes out.
A Google Sheet is the simplest integration. Make.com’s Google Sheets module is stable, the row-based structure maps cleanly to posts, and you can add a “Status” column to flag which posts are ready. The downside is that editing long-form text in a spreadsheet cell is unpleasant, and you lose any rich editing experience.
Notion has a better writing experience and lets you draft posts in actual text blocks, but the Make.com Notion module is slower and occasionally inconsistent when pulling property values alongside page content. It works, but requires more error handling.
Airtable sits in between: a spreadsheet-like structure with richer field types and a more reliable Make.com integration than Notion. I ended up with Airtable. The decision came down to one thing: I wanted a “Status” select field that was easy to filter on, and Airtable’s single-select fields are faster to update on mobile than either a Google Sheet dropdown or a Notion property.
The column structure I settled on: Post Body, Status (Draft / Ready / Published), Scheduled Date, and a Notes field for context I want to remember when reviewing the post. That’s it.
How the Make.com Scenario Is Actually Wired
The core scenario is straightforward. A scheduled trigger fires once a day in the morning. It calls Airtable to fetch any row where Status = “Ready” and Scheduled Date = today. If it finds one, it passes the post body to the LinkedIn module and creates a share. Then it updates the same Airtable row to Status = “Published.”
The complexity isn’t in the modules. It’s in two places: formatting and failure handling.
Formatting. LinkedIn doesn’t render markdown. Line breaks in your source content don’t translate automatically to line breaks in the post. You have to handle this with a text formatter in Make.com, specifically a replace function that converts your line break characters to the literal newline format LinkedIn’s API expects. If you skip this step, posts go out as one continuous paragraph.
Failure handling. Make.com scenarios fail silently unless you build error handling in. I added an error route that catches any failed LinkedIn API call and sends a Slack message with the post content and the error code. That way if the token expires or LinkedIn returns a rate limit error, I know within the hour instead of finding out three days later when I notice nothing has posted.
The Task Master workflow I’ve written about before follows the same basic pattern: a trigger reads a source, calls an API, and updates a status field. The LinkedIn scenario is a bit more involved because of the formatting layer, but the architecture is identical.
What Broke on the First Pass
Three things failed before the scenario worked properly.
The first was the line break issue described above. Posts went out as walls of text. Fixed with a text formatter module between the Airtable read and the LinkedIn post.
The second was date comparison. Make.com’s Airtable module returns date values in ISO format, and I was comparing them to the current date using a simple equality filter in the module settings. This worked when the scenario ran at exactly midnight UTC, and broke every other time because the time component of the timestamp didn’t match. Fixed by using the formatDate function to strip the time component and compare date strings only.
The third was the token expiry. Two months after the initial build, the scenario stopped posting. No alert because I hadn’t built the error route yet. Found out when someone mentioned they hadn’t seen anything from the LinkedIn page in a while. Added the error handling after that. This is the same principle The Self-Managing Business covers in the final chapter on locking systems: a system that depends on you remembering to check it isn’t really running without you. The error route made the scenario self-reporting.
The Trade-offs Worth Knowing
The main trade-off in any scheduled distribution setup is consistency versus context. A post that goes out at 8am on Wednesday because you wrote it two weeks ago is exactly what was written two weeks ago. It can’t reference something that happened yesterday. It won’t pick up on a thread that went viral this morning.
That’s not necessarily a problem. Most evergreen content doesn’t need that kind of currency. But it’s worth being clear-eyed about what you’re optimizing for. If your LinkedIn presence is primarily a thought leadership signal, scheduled automation works well. If you’re trying to be responsive and part of real-time conversation, automation handles the base layer and you still post manually when something timely comes up.
The other trade-off is approval gates. I chose not to add one. The scenario reads “Ready” posts and publishes them without a human confirmation step. That means if I mark something Ready and then decide it’s not quite right, it goes out anyway if I don’t catch it before the morning trigger fires. For low-volume posting (three or four times a week), that’s an acceptable risk. For anyone running higher volume or with more stakeholders, adding an approval step is straightforward: add a “Approved” status and change the filter condition.
A system that runs without motivation is the goal, but not at the cost of control you actually need.
What the Working Version Looks Like
On a Monday, I write three or four posts in Airtable, set their dates, and flip the status to Ready. The Make.com scenario runs every morning and handles the rest.
Total ongoing time: ten to fifteen minutes a week on the content, zero on distribution. The scenario has been running without intervention for months, except for the quarterly token reconnect I now have a calendar reminder for.
What it doesn’t solve: writing the content. That still requires thinking. The automation just removes the part where thinking was done but the work didn’t happen because posting felt like one more thing to do at the end of the day.
If you want to build something similar or you’re not sure whether your process is ready to automate yet, the Work With Me page has the details on how that engagement works.
Frequently Asked Questions
LinkedIn has not confirmed an official reach penalty for auto-posted content, and most practitioners report no consistent difference at low posting volumes. The more likely impact is on engagement timing: an automated post goes out at a fixed time regardless of what’s happening in your feed that day, so you may miss moments when manual posting would have caught a trending topic or active thread. For evergreen content posted a few times a week, the trade-off is generally worth the consistency gain.
Yes. The Make.com LinkedIn module supports both personal profiles and company pages. For company pages, your LinkedIn account needs page admin or content admin permissions. You select the page in the module settings using its organization ID, which you can find in your LinkedIn page admin panel under “Super admin” settings.
The Make.com connection silently stops working. The scenario will run but the LinkedIn module will return an authentication error, and unless you’ve built an error route, you won’t know until you notice nothing has posted. Fix it by going to your Make.com connections, finding the LinkedIn connection, and clicking Reconnect. LinkedIn access tokens issued through Make.com expire after 60 days. A recurring calendar reminder to reconnect at the 55-day mark prevents the outage.
The same architecture works with either. Zapier has a LinkedIn integration that supports text posts and is slightly simpler to configure, but costs more at volume. n8n has a LinkedIn node and is open-source, so it’s free to self-host, but it requires more setup time. Make.com sits in the middle: more flexible than Zapier, more polished than n8n, and priced reasonably for the operation count this kind of scenario uses.
LinkedIn’s API accepts plain text with literal newlines. If your content source uses markdown line breaks or any formatting syntax, you need to strip it before the post goes out. In Make.com, use a Text module with a replace function to convert \n characters to actual line breaks, and a second replace to strip any markdown syntax (asterisks for bold, underscores for italics) since LinkedIn won’t render those either. A text post that looks clean in Airtable will go out garbled if you skip this step.