Difference between revisions of "Benefits of a Shadow Application"
From SmartWiki
| (9 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
A shadow [[Application|application]] is a second [[Universal Tracking Application]] linked to an original [[UTA]]. The purpose of a shadow [[Application|application]] is to provide an alternative interface to a [[UTA]] in circumstances where the security matrix and field level security is not sufficient. Typical uses of a shadow [[Application|application]] would be: | A shadow [[Application|application]] is a second [[Universal Tracking Application]] linked to an original [[UTA]]. The purpose of a shadow [[Application|application]] is to provide an alternative interface to a [[UTA]] in circumstances where the security matrix and field level security is not sufficient. Typical uses of a shadow [[Application|application]] would be: | ||
* Providing the same [[UTA]] in a different language. In this scenario the labels of the standard fields in the shadow [[Application|application]] would be added in the alternative language. Alternative language versions of each [[Custom Field|custom field]] would be created, and each field mapped to the original [[Custom Field|custom field]]. | * Providing the same [[UTA]] in a different language. In this scenario the labels of the standard fields in the shadow [[Application|application]] would be added in the alternative language. Alternative language versions of each [[Custom Field|custom field]] would be created, and each field mapped to the original [[Custom Field|custom field]]. | ||
| − | * Providing simplified Access to an existing [[UTA]]. In this scenario, limited standard fields would be selected (though the parent [[Application|application]] may include all standard fields), [[Custom Field|custom fields]] are restricted by [[Role|role]], and the list | + | * Providing simplified Access to an existing [[UTA]]. In this scenario, limited standard fields would be selected (though the parent [[Application|application]] may include all standard fields), [[Custom Field|custom fields]] are restricted by [[Role|role]], and the [[List View|list view]]s of the [[Application|application]] can be controlled separately to the original [[Application|application]]. |
| + | * You can control how many levels from the parent application you wish to use. | ||
| + | * You can control which [[Templates]] (Level 1) or [[Types]] (Level 2 '''only''') are available in the Shadow Application. | ||
| + | :: '''Note:''' if you enable Level 3 in the Shadow Application all Level 3 [[Types]] defined in the parent [[UTA]] will automatically be available in the Shadow App. | ||
| + | * You can control which [[Statuses]] are available in the Shadow Application. | ||
| + | * You can set custom [[Submit Logic]] for the Shadow Application. If no submit logic is set, then the submit logic from the parent UTA will be used. | ||
| − | |||
Each Shadow [[Application|application]] has its own security matrix so you can control access within each [[Application|application]] separately. | Each Shadow [[Application|application]] has its own security matrix so you can control access within each [[Application|application]] separately. | ||
| Line 11: | Line 15: | ||
==See Also== | ==See Also== | ||
* [[Creating and Enabling a Shadow Application]] | * [[Creating and Enabling a Shadow Application]] | ||
| + | * [[Setting Manager Permission to the Shadow Application]] | ||
| + | * [[Configuring Templates and Statuses in a Shadow Application]] | ||
| + | * [[Security Matrix and the Shadow Applications]] | ||
| − | + | {{PrevNextStart}} [[Reader Logs]] | |
| − | [[ | + | {{PrevNextMid}} [[Creating and Enabling a Shadow Application]] |
| + | {{PrevNextEnd}} | ||
| + | [[Category:Universal Tracking Application]] | ||
Latest revision as of 15:01, 25 September 2013
A shadow application is a second Universal Tracking Application linked to an original UTA. The purpose of a shadow application is to provide an alternative interface to a UTA in circumstances where the security matrix and field level security is not sufficient. Typical uses of a shadow application would be:
- Providing the same UTA in a different language. In this scenario the labels of the standard fields in the shadow application would be added in the alternative language. Alternative language versions of each custom field would be created, and each field mapped to the original custom field.
- Providing simplified Access to an existing UTA. In this scenario, limited standard fields would be selected (though the parent application may include all standard fields), custom fields are restricted by role, and the list views of the application can be controlled separately to the original application.
- You can control how many levels from the parent application you wish to use.
- You can control which Templates (Level 1) or Types (Level 2 only) are available in the Shadow Application.
- You can control which Statuses are available in the Shadow Application.
- You can set custom Submit Logic for the Shadow Application. If no submit logic is set, then the submit logic from the parent UTA will be used.
Each Shadow application has its own security matrix so you can control access within each application separately.
You can consider this application as a “customer” view of their contracts.
See Also
- Creating and Enabling a Shadow Application
- Setting Manager Permission to the Shadow Application
- Configuring Templates and Statuses in a Shadow Application
- Security Matrix and the Shadow Applications
