You can’t add new global merge syntax but if you need to get your information through merge syntax you can create a UI only model, add fields to the model, modify the fields with the session information and access the information using model syntax {{$Model.modelname.data.0.FieldName}}.

What exactly are you trying to do? Do you know that you can use javascript in skuid with snippets?

I saw that somewhere.  Just getting started learning Skuid.  Seems pretty powerful but so many new things to learn and the approach is different that the traditional C# programming approach.

Here’s what I’m trying to think about.  If I have 100 customers in my database, each with their own companyid, I want to filter any data I show this customer by their companyid.  I plan on having a login page where they present their credentials and I look up their companyid.  I store this ID in my “session table” and use it to filter all other information for them.  I will also want to capture role, etc.

I’ve built a large multi-tenant application in the past on a traditional web platform and I’m trying to emulate my approach in Skuid.  I think I can do it but big learning curve.

The Skuid for Salesforce approach would be to create model conditions on your models to filter out the data you don’t want the user to see.
http://help.skuid.com/m/models-conditions-filters/l/102653-what-are-conditions

However, this isn’t used as a security mechanism, but rather for interface design. Salesforce handles row level security on its own.

Since you’re having users access a database that supports authentication it sounds like you might want to have the users authenticate themselves, and have your models be security blind. You can have the users authenticate themselves using user specific credentials.
http://help.skuid.com/m/models-conditions-filters/l/530857-authentication-and-skuid

Mark,

You will want to use record sharing to govern access to the records themselves.  Salesforce has good support for this.  Look at the Sharing Rules paragraph here->  https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_bulk_sharing_understan…

You may be able to adjust sharing settings and use criteria based sharing.  This will keep you in the declarative world.  If not, you can create some Apex classes to handle the assignment of access per record.

Thanks,

Bill

Thanks! This sounds like it has potential.  I’ll look into it further.  As you said in the second paragraph, this is not exactly about security once a user authenticates.  I need to know their company id so I can restrict the data I show them.

Hi Bill,
Thanks for replying.  However, I’m not using the Salesforce version of Skuid.  I’m using the Skuid Platform hosted at Amazon Web Services.
Mark

Hi Mark. It sounds like you’re looking to first authenticate users, and then manage what they should see. One of the tools for this is managing access to apps. Basically, an app is a set of one or more pages you’ve built. An admin can give users access to any apps you’ve built on Skuid. 

Separate from apps, you are also able to specify Data Source Access separately for each profile (admin, standard user, etc.). If the standard profile has access only to Data Source X, then any users with that profile would be able to see that data source. If a page in an app has models that are connected to Data Source X and Data Source Y, then a standard user who loads that page would not see any components or data that are associated with Data Source Y (they’d see everything that pertains to Data Source . 

So at this time, you are able to set up data sources separately (with different scopes, and so forth), and attach them to an appropriate profile. You’d set up various apps and app permissions to present the data appropriately. Say, perhaps, you have a set of users who should be associated with Company Q. You would set up a data source and authentication connection to wherever your data lives, and on your data source, set up the scope such that only Company Q is accessible. 

Quite a lot is already possible, and our dev team is working to expand the toolset for permissions and security. If you haven’t already seen it, here’s our documentation for data sources and user and permission management for Skuid Platform. 

I should add that you can clone one of the built-in profiles and customize that clone. That’s an important piece of what I just described. To do this, you’d click Configure > Profiles, and click the pencil for the profile to clone. The next page will offer a Clone button in the top right corner. Once you’ve done this, you’ll be able to fine-tune that profile, say for use with Company Q users. 

Mark,

That’s great!  You will definitely want to follow Mark DeSimone’s advice regarding how to secure your data.

Best of luck!

Bill

He’s not using Skuid for Salesforce. He’s using Skuid Native.

Oh! Just read Mark DeSimone’s answer. Should have looked first!

Great information. Thanks Mark!

Hi Mark,
Thanks for responding.  There’s a lot going on here, both in what you’re providing me and what I’m trying to do.  Skuid doesn’t seem to offer what I want exactly right out of the box but I’m pretty confident that there are viable work-arounds.
Would it be possible to have a phone call to discuss more thoroughly?
Thanks,
Mark

Mark Ebersole,

Can you please post your findings when you figure it out? This page could be really helpful for future questions.

Yes.  In a nutshell, I’m wanting to build a SaaS product using Skuid that allows my customers to assign their own users with roles(profiles), login ID’s/passwords, and security level(RO/RW).  Each customer would have their own company ID and all related data would be identified by that company ID. That means that each set of data presented would be filtered by that ID.  

Essentially, I’m building a SaaS product sitting on top of your SaaS product.  API’s would be nice to access all your existing user/authentication services but most of it can be built on top.  All my users would first come to my public page that would have a login link that presents a page to collect loginID and password.  I would have to store that information for their session globally and use it to filter all aspects of the app.  

A newly acquired customer would be assigned a Security Admin role by me that would allow them, in turn, to do all the remaining provisioning for their company.

I’m sure there are ways to get this to work and I’ll report back when we figure it out.