Look, it's more talk about application scopes. I told you this was a big deal. Today we'll cover the settings that control access between application scopes. By access, I mean access to data as well as configurations on tables in other scopes.
The initial use cases you'll come across is how your custom application scope will interact with ServiceNow delivered tables. However, this concept applies to all tables in any scope. For Fuji, all ServiceNow application tables reside in the "global" scope. I could see this potentially changing in future releases as there might be value in isolating applications such as the latest non-IT process apps from the IT and each other.
We'll cover additional application access controls in future posts. For now we're going to cover table access. When you open a table record (System Definition -> Tables) you'll see new properties on the form under the Application Access section. These are the controls that determine how other application scopes can interact with the specified table.
You'll also see an Application field. This will show you the scope that owns the table. All data and process within a scope work just as they always have.
When we talk about access to a table from other scopes, we're not talking about security (ACLs) as you would normally think of it. Access, in this case, means can an application process from another scope read or write to this table. For example, I create a new application scope with a table called outside_tickets. If I want to reference the incident table from outside_tickets, my new scope needs read access on the incident table.
The good news is that most of tables that your application will interact with are already configured for read, create, and update access as well as being accessible via web services.
As we can see in the screenshot, we cannot make changes to a table outside our current scope. My current user session is working in the CAVUTest scope and the incident table is in the global scope. I can easily switch to the global scope and make any changes. This is a fine solution if you are building a stand-alone application for yourself or a single customer. However, if you're planning on bundling the application and distributing through the marketplace, you need to be aware that these changes will not and cannot be captured in your application package. This means the customer will have to make the configuration change manually. I'm sure this is another process that we'll eventually see automated in a future release.
Another options on the table form is Allow configuration. This allows you to create configurations such as business rules, UI actions, and even fields on the table, but include them in your application scope. This is critical when bundling an application for the app store. Just remember that you'll need to perform any changes to the target table's application access manually for now since it won't be bundled in your application package.
The last option we'll cover is the "Accessible from" choice field. All of the access controls we just reviewed were available because this table is available to "all application scopes". The only other option is "this application scope only", in which case we wouldn't need to worry about the individual controls. Remember, all access and configuration is allowed within a scope.
Ideally, I'd like to see this enhanced to allow access to one or more scopes instead of an "all-or-nothing" model. This will allow for very specific data access like we're all used to seeing when applications want to access your Facebook friends or Google data. I'm sure it's in the backlog somewhere for Geneva (hopefully).
Lastly, be sure to checkout the related documentation as it goes into a little more detail. It will also be updated with any change that might come up in future Fuji patches.