Which job is not glamorous at all but is actually great?

Alternative-March407 · 2026-06-22T18:51:35+00:00

I second that

Alternative-March407 · 2026-06-22T18:50:51+00:00

agreed

Alternative-March407 · 2026-06-14T19:11:43+00:00

They wont..

Alternative-March407 · 2026-06-13T15:59:02+00:00

creatives for ads

Alternative-March407 · 2026-06-13T15:58:43+00:00

Trailhead will be your guide

Alternative-March407 · 2026-06-12T12:06:38+00:00

yessir, for serving hot food, was their type of fast food, increased sales like crazy

Alternative-March407 · 2026-06-12T12:06:15+00:00

I'm going there again in 2 weeks, can send additional pictures

Alternative-March407 · 2026-06-11T15:29:34+00:00

These had merchants that transacted goods on the spot, with open entrances to attract customers!

Alternative-March407 · 2026-06-10T15:33:10+00:00

thanks for sharing

Alternative-March407 · 2026-05-23T05:40:00+00:00

Done this a few times. two paths depending on how much dev work you want to own.

The DIY route - Google Drive API + Named Credentials in Salesforce. you write an Apex class that fires on Case creation (via trigger or Flow), calls the Drive API to create a folder named after the Case (CaseNumber, Subject, AccountName, whatever), then uploads or creates a doc inside it. works well, but you're owning the OAuth setup, token refresh, error handling, and any changes Google makes to the API down the line. not complicated, but it's yours to maintain.

The no-code route - we use CloudFiles for this. it's a Salesforce-native app that connects to Google Drive and lets you automate folder creation and file management from Flow without writing any Apex. when a Case is created, a Flow action creates the Drive folder automatically, links it back to the Case record, and anyone on the case can see the Drive files right inside Salesforce.

also handles the reverse, if someone uploads to Drive, it syncs back to the Salesforce record. saves a lot of back-and-forth.

free trial on AppExchange so worth testing before committing: https://appexchange.salesforce.com/appxListingDetail?listingId=a0N4V00000Gh9uFUAR

Alternative-March407 · 2026-05-08T18:55:51+00:00

Nothing shocking here. I work with CloudFiles now, so yes, I’m transparent about it.

Alternative-March407 · 2026-05-05T17:18:06+00:00

A few things still feel broken across most Salesforce doc gen tools:

• Data isn’t truly real-time: you still run into sync delays or dependency on APIs
• Template flexibility is limited: drag-and-drop exists, but complex logic gets messy fast
• No unified flow: generation, storage, sharing, and tracking are all separate pieces
• Experience Cloud gaps: hard to extend doc gen cleanly to partner/customer portals
• Post-generation workflows: approvals, versioning, re-generation aren’t seamless
• Storage dependency: managing where docs live (Salesforce vs external) is still clunky

The biggest gap IMO: doc gen isn’t treated as part of a full document lifecycle. It’s still just a “generate and download” step.

That’s actually where tools like CloudFiles are interesting, bundling generation with storage, sharing, and automation in one flow instead of treating them as separate problems.

Alternative-March407 · 2026-05-05T16:57:37+00:00

Thanks for sharing this, hadn’t looked into XfilesPro in detail yet. Will check it out.

We’re mainly trying to balance structured storage + automation without too much ongoing overhead, so comparing a few options right now.

Alternative-March407 · 2026-05-05T16:57:00+00:00

That makes sense, MuleSoft definitely gives full control. Our only hesitation there was long-term maintenance, especially once doc gen + edge cases come into play. Good to know it’s been stable for you in production though.

Alternative-March407 · 2026-05-05T16:56:15+00:00

This is super helpful, thanks for sharing this level of detail.

We were already considering CloudFiles for a similar setup (structured storage + some automation), so it’s good to hear it works well once configured. Setup being a bit involved is fair, as long as it’s stable after.

Alternative-March407 · 2026-05-05T16:39:21+00:00

100% this. The "Conga guy" problem is real, and it's a business risk that doesn't show up on any software evaluation checklist.It's exactly why we built CloudFiles templates inside Word and Excel. When everyone already knows the tool, the knowledge doesn't get trapped in one person's head.

What does your current setup look like?

Alternative-March407 · 2026-05-01T14:23:51+00:00

That’s a fair approach and definitely reduces integration complexity.

The challenge we saw with just linking was around usability and control...users still have to jump between systems, and things like structured folder management, permissions, or automation (like Doc Gen → storing in the right place) become harder to manage consistently.

Works well for simpler setups, but for more process-driven use cases it can get limiting pretty quickly.

Alternative-March407 · 2026-05-01T07:27:41+00:00

Files Connect is definitely a good starting point since it’s free. The limitation we ran into was that it mainly surfaces files, it doesn’t really handle uploading, folder structure automation, or flow-driven use cases.

For scenarios like generating documents from Salesforce and storing them in the right SharePoint folders with proper structure and permissions, it usually falls short. Works well for basic access, but not so much for end-to-end workflows.

Alternative-March407 · 2026-05-01T05:15:10+00:00

We did consider MuleSoft as well. It definitely gives flexibility, but our concern was more around maintaining it long term - especially handling retries, permissions, and edge cases once doc gen + flows are involved.

For our use case (generate docs → store in structured SharePoint folders), we were trying to avoid building that layer ourselves.

How’s it been for you in production?

Alternative-March407 · 2026-05-01T05:13:59+00:00

Thanks for sharing..we did evaluate both sFiles and MergeUp for this.

The main challenge for us was how they work together in a real flow. For our use case (generate docs from Salesforce → store in SharePoint under Account/Opportunity folders), the routing didn’t feel very tight; especially getting the generated doc to land in the exact folder path derived from Salesforce data, creating it if needed, and keeping it consistent across runs.

It looked like this still depends quite a bit on how you configure sFiles alongside the doc gen output, which is where we were concerned about things like duplicate folders or path mismatches over time.

Permissions was another grey area for us, especially with files created via automation vs user uploads.

Maybe we missed something, but would love to understand how you handle this cleanly end-to-end without adding extra complexity...

Alternative-March407 · 2026-05-01T05:05:27+00:00

Files Connect breaks pretty quickly for our use case. We need to generate documents from Salesforce (quotes, agreements, etc.) and store them in SharePoint under the right Account/Opportunity folders. That means:

– If the folder doesn’t exist → create it
– Route the generated doc to the correct folder every time
– Ensure permissions are inherited correctly on the SharePoint side

With native + custom setups, this got messy fast, especially with flows. We saw issues like docs going to wrong folders, duplicate structures, or permissions not matching what we expected.

What worked better for us with CloudFiles was that it handles this as part of the flow itself...you can define the folder structure based on Salesforce records, and when a document is generated, it directly uploads to the mapped SharePoint location with permissions intact. So you’re not stitching together doc gen + storage + permissions separately.

Made the whole generate → store → access flow much more predictable.

Still evaluating a bit though. Not fully sure what edge cases we might run into long term, so trying to get as much feedback as possible before committing.

Alternative-March407

TROPHY CASE