Question on messaging by James Alan Hall, on 26/2/21: I asked this before and the answer was negative… checking in to see if this has changed. The big limitation is not being able to share records across applications. Has this changed ? For example I have client information in the CRM, then I should be able to reference the same contacts in the Service module. If I build a customer portal then that would also need to share data with the CRM and Service module.
Records from one application (namespace) can still not be accessed from another application and I can’t promise this will change any time soon (if at all)
I see two solutions here:
- you define automation scripts that let you sync records between different namespaces.
- you define a new application (namespace) that contains all of the things that you need instead of having multiple namespaces.
We usually go with the second option when we need something that would need to share data between namespaces.
@Lenny did this change from last year ?
Will there be any workarounds to read records from another namespace with the standalone tables of version 2022.9 ?
As is, you could use stand-alone tables to share data between different low-code applications (and even different applications altogether).
I don’t think we’ll/should add any restrictions in regards to this; what do you think @darh ?
1 Like
The use case scenario could be a namespace that contains some global tables (modules) that every other ns might use instead of duplicating them in every namespace.
1 Like
The idea of namespaces is exactly that – to separate data. Same thing as you do with multiple databases or schemas and tables.
We might allow modules to have global exposure but this will likely to open a set of other problems. Starting with permissions - permissions for each module are partially based on permissions set on namespaces.
1 Like
Indeed, that’s what namespaces are. But when we try to make complex solutions, we find ourselves quickly in need of shared data between all apps.
Does a report with data from different namespaces have the same permission complications ?
If the permission problem is too complicated, is it possible to put different low code apps under the same namespace ? I tried to put all module together but it became not very user friendly
Have you considered automation to keep the data synced between the namespaces?
Reports have their own special can-run permission just for that.
If the data is tightly coupled it could be worthwhile move all of the modules under the same namespace and reconsider the structure to simplify it.
1 Like
That’s what I am doing right now.
Thank you fir your precise response !
Cheers
1 Like
A possible solution could be achieved if corteza review the module menu.
The idea could be that in menu I can create 2 levels:
FIRST LEVEL: app name
SECOND LEVEL: list of module in app
I.e. in CRM prebuild namespace I can have
SELLING with opportunity, quote, etc.
SERVICE with case, etc…
MARKETING with campaign, etc.
The same module should be possibile to add in different “APPs”.
2 Likes
Hi there.
I am currently facing this problem as well for compartmentalizing applications. I think i found a solution however. I wanted to developer input on whether it is a good idea or what if anything would break.
Essentially, for the module i want to share between applications, I go to Data store and set the database table name to a specific name rather than the compose record default.
I then uncheck the namespace ID on the system field mapping/encoding to prevent an error and save.
Then i export the whole module and reimport it in a separate namespace that i wish to have the shared module duplicate module.
My thought process is that with the data being stored in a dedicated table, and both modules having the same configured fields, and pointing to the same table by having the same data store configuration then the information would be accessible in the same way.
And it works! My question now is, how good an idea is this? What could break? Are there permission hiccups I would need to worry about?