The CreatorCon Call for Content is officially open! Get started here.

What is your criteria for creating a Scoped Application?

Joey Wan Kenobi
Tera Guru

Since I heard about scoped applications, I've been confused about when to build them. Especially considering that an applications can also be built as a Standard Catalog Item (on the sc_cat_item table). Any of the fields can be made as variables; flow logic is inherent to a standard catalog item; tasks are inherent to the flows, etc.

 

So, my question is:

How do you decide when to make a Scoped Application?

How do you evaluate whether an application is necessary versus a Standard Catalog Item?
What criteria/questions go into saying - "this use case is better suited a Scoped Application?"

 

Okay that is 3 questions, but they are different ways of asking the same thing. 

 

So far, I've come up with these - 

- Does reporting need to be leveraged? (because reporting on standard catalog item variables is a pain)
- Is stakeholder administration and/or delegated development needed?
- Are there specific access controls needed (rather than bog down ACLs for sc_req_item and sc_task)?
- Is it going to be more complex (how many variables is "too many")?
- Does it need to iterate (aka versioning)?
- Will it be shared?
- Is there a use case for integrating it with other tools
- Are specific business rules needed?

 

I feel like there are more. What else should be included or changed on this list?

3 REPLIES 3

Hi,

Please refer to my original question. I'm not asking what application scope is, I'm asking about considerations for when to use it. Like, knowing what a convection oven is is different from knowing when to use it. 

Joey Wan Kenobi
Tera Guru

Perhaps the question could be addressed in reverse:

 

"Don't create a standard catalog item if..."

...You need to write business rules or ui policies on sc_task just for this item

...You have X number of variables

...You need to dotwalk on reports

 

join in... what else?