[rtpg]

My glib take to every CRM like this: If you don't ship with a programming layer you're DOA. Salesforce thrives off of Apex and friends. You _need_ to let people program your CRMs if you want to go after SFDC. Or, more specifically, you need to _host_ people's programs so they don't have operational questions.

Salesforce gets the ubiquity the same way that Wordpress does: randos can copy some code fragments off of a website and stick it into a file/textbox, and get new functionality.

So... Twenty, hire one person whose job it is to layer AWS Lambda over your system :)

[iFelix]

Hey, just seeing this thread now. Agreed! We've started a year ago and have done probably just 10% of what is needed to really get to Salesforce. We need (1) a flexible data model, (2) a flexible layout, (3) code execution. We've done (1) but have yet to do (2) and (3) this year. Next step of the plan is to let people build and share apps that leverage those 3 blocks, that's where open source will really shine!

[andyferris]

Can you elaborate on what "a flexible layout" means in this context? Is this data layout, i.e. serialization format(s)? UI layouts for displaying values in the data model? Something else?

(We too are in the "let people execute their code on our servers" space; providing a flexible data model seemed to have been key)

[schneems]

I work for a Salesforce company (Heroku) so I’ve used their CRM interface enough that I think I know what they are talking about.

You can customize views and reports. To the point you can make it do stuff like be a kanban board or blog. It’s really flexible. The “build a portfolio” is actually using the CRM (IIRC). https://trailhead.salesforce.com/content/learn/trails/build-...

[dewey]

Most businesses are not big enterprises that need a programming layer. You can focus on that later on when you actually found some traction and move up-market. I don't think starting with enterprise features is "DOA", it's just smart prioritization.

You don't want to go through enterprise sales cycles when you are just starting your company.

[cfiggers]

> Most businesses are not big enterprises that need a programming layer.

Your assumption is that having a programming layer in a CRM is only for big businesses. But that's not true at all.

[lelanthran]

> Your assumption is that having a programming layer in a CRM is only for big businesses. But that's not true at all.

I read it to mean that "A programming layer in a CRM is only for those businesses that can afford a programmer", which, TBH, are only big businesses.

Which is why small companies may not be able to afford making Salesforce fir their needs exactly - the cost to hire consultants to come in and panel-beat the system to fit is higher than the cost of continuing with spreadsheets.

[cfiggers]

> "A programming layer in a CRM is only for those businesses that can afford a programmer", which, TBH, are only big businesses.

That just is not the case. My first job was working as a solo Salesforce admin/dev for a company of < 150 employees and we made extensive and valuable use of the Apex layer.

Your assumptions are inaccurate, and that is leading you to inaccurate conclusions.

[andyferris]

Right - presumably the target market are people wanting something other than Excel or Google Sheets, which they likely already use programmatically not just for data entry. Is that right?

[shortrounddev2]

I've worked with big and small businesses that use salesforce and they all have some kind of programming layer. Small businesses tend to buy plugins or pay some contracting firm to write customizations.

[rtpg]

> You don't want to go through enterprise sales cycles when you are just starting your company.

There's definitely a gradient here. If you are good at juggling sales cycles, you can close "small enterprise" deals. And if you have a good programming layer, instead of going through a full dev process for each thing, you get "integrators" working on things.

The advantage here: once the design is done, you're writing a handful of 10-line scripts. You can have a design meeting, have a person sit down for an hour, and ship out a thing that closes a deal. And the design can be done for _just_ the company's needs instead of a full flow. You can charge an "integration fee" to the customer in this case as well.

A programming layer lets you remove a huge level of tension that comes with B2B sales: juggling specific client needs with your product needs.

[harel]

I run a CRM platform for many years. And while this is true, that if you want to go after a subsection of SalesForce type customers, you do need a programming layer. However, that is only a specific section of the market. There are vast amount of users out there that do not need that and will never will. They need a CRM. Not a Platform-that-is-also-a-CRM.

We offer 100% API access, and customisation from the data layer to the UI (very very flexible), but I'd be reluctant to invest time in adding an actual programming layer like APEX on top of it. I don't think I'd want to even go to that level of "enterprise" customers and everything else that comes with it.

Edit: just because I've seen people plug their products here as well, I'll add mine: https://cogmento.com

[EricE]

I just want ACT! back before Symantec ruined it :p

[harel]

Oh wow I completely blanked ACT out of my memory... That comment was like a wet slap to the face... :-)

[debarshri]

I think it is easier said that done. The GTM completely changes of a product like this. Now you have to build API, DSL and eco-system to support it. I absolutely agree that your take. But building an eco-system is hard.

[rtpg]

You don't need a DSL if you, for example, "just" use Javascript. You need an API anyways. You do need to do some operational fudging around of course.

I'm going to also counter with something super important: you build out stuff like this, and suddenly you can handle your own feature requests faster. User wants X to happen after Y? Write a tiny event script that they install into their env. They need some bespoke field? You have custom models, and now your events reply to that.

In the fractal of requirement differences that is sales pipelines, not doing this just feels like causing yourself a bunch of dev pain.

[meekaaku]

I agree with this.

From a technical perspective, how would one structure a program like this? Where the main developers also use the same 'engine' to develop the product itself, while also exposing the same engine to the third parties?

The first such case I have seen was Maya (the 3d software) when it first came out use a custom scripting language called MEL(Maya Embedded Language) to develop the entire user interface and corresponding actual entity manipulations. Third party plugin developers also use the same MEL.

I thought wow, and that is still impressive today.

[JWlrCk9PkipFTDq]

I work with a CRM that allows users to add additional functionality by uploading definitions in XML "spec" files.

The XML specs are a combo of metadata and code and define all functionality in the system including SQL tables, forms for adding/editing data, query nodes for the internal query system, arbitrary business processes etc. They can include SQL stored procedures to run or call out to bundled C# code, and they can be accompanied by HTML templates that generate UI elements where appropriate (e.g. user facing forms).

There are a lot of moving parts and the documentation is a bit patchy but it's a really ingenious system for adding modular functionality, particularly in a CRM setting. Pretty much all of the "official" functionality is built using this spec system.

[meekaaku]

But would not that be a maintenance nightmare with code with xml and lack of version control.

Also how does one restrict to a particular tenant

[lelanthran]

> You don't need a DSL if you, for example, "just" use Javascript.

I'm in agreement, but I think you still need to build tooling around it.[1] At the very minimum:

1. The code editor needs to be part of the system - pointing the customer at VS Code is a dealbreaker.

2. Debugger needs to be provided: you can't ask the customer to hit F12 and learn how to use the browser's devtools.

3. Documentation is still needed: At least one folder of samples/examples, and at least a single exhaustive reference of all the functions provided by system.

Finally, I wouldn't go with Javascript: Non-developers are less-likely to understand something as complicated as Javascript.

You're using a language that has subtle and hard to find bugs if variables are declared in one of three ways, when a different way is more appropriate. Same with the two different ways to define functions. Same with the difference between all the forms of a for loop. Same with the distinction between a prototyped object and a class. Same for the usage of instance variables vs class variables.

Add typescript support to the mix and you may as well not even bother looking for customers.

[1] I just created a system that uses a vanilla webcomponent for client-side includes of HTML snippets, using only HTML. It's not possible to now set breakpoints in any `script` element that is included using this webcomponent, e.g. `<my-include remote-src=./common-stuff.html>` where `common-stuff.html` has script tags.

[kitd]

This is a developer's answer to a business problem. Scriptability added to a non-developer's tool is usually just enough rope to hang them on IME, and often ends up in a whole arsenal of footguns.

[moneywoes]

So just re-use your own internal apis with better access control? What else?

[eropple]

IME, this is how an enterprise-contender product should generally be built when it wants to touch many domains across the business. Starting with a reasonably rigorous access control model enables deeper business integration--and this is a product that, to be successful, can't live without that.

[projektfu]

Man, if only SaaS would do just this instead of reinventing the wheel with their brain-dead scripting languages and limited APIs where they remove useful information and links between data.

[moneywoes]

SFDC for the uninitiated?

[eropple]

"Salesforce dot com". "SF" would be a little hard to differentiate.

[iamacyborg]

Salesforce sales cloud, the core crm app. As opposed to other apps like marketing cloud (sfmc) and others.

[floating-io]

Certainly not SDLC.

That's what I read it as the first time through. How annoying.

[victorbjorklund]

Not sure. In my experience a lot of companies dont do any custom coding for their CRM and if they do it is usual basic stuff that can be done with a zapier integration (add lead to CRM when form is filled). An API is probably good but dont think every CRM customer needs APEX level API.

[slig]

They could somehow whitelabel and embed Windmill.

[rubenfiszel]

Yes, we(Windmill)'d be a kick-ass combo. We're users of twenty ourselves. As both open-source projects, a third option that I'm often recommending is having such great integration in both products such that their users can independently chose to use and install Windmill (self-host or cloud) and have it power all of the orchestration and arbitrary-code needs of the third service without the need for a formal whitelabel.

[robertlagrant]

If they could inject their data model into the Windmill IDE so autocomplete worked, that would be...very good.

Edit: also - just to say this now, because I always say it, but having a way to embed this stuff into normal software development flows, with Git / code review / CI / test automation / Docker (maybe) / different environments would be very helpful.

I don't know if you do or not, but my main problem with anything like this is the makers are really keen to show me how easy it is to put stuff into production with 3 clicks, and that's the last thing I want. If I went back into business systems, I'd want a great tool that lets me support a large business with a tiny software team, so the business doesn't have to try and replace software people with business analysts because you need too big a software team to run it cost-effectively.

[rubenfiszel]

It wouldn't even be that hard since we have our own layer on top of monaco to resolve types that could dynamically fetch it from Twenty.

[DANmode]

You're supposed to wait for the CTO interview.

[ssahoo]

What is the difference between Salesforce and low code platforms then?

[unixhero]

Yes

Programming And Workflows are keys