The internal/external distinction is used to identify the profiles and applicants that are registered with your office's institution and those who are registered with other home/partner institutions. Programs, process elements, and applicant parameters can be configured to apply only to internal or only to external applicants.
- An external applicant will usually be one that has provided their name and email address to your site to obtain login credentials.
- An internal applicant is one that is registered with your office's institution. If your site is integrated, these applicants will login using their institution credentials and their core information will be automatically populated from your information system.
Configuration of Internal and External applicant types
There are a number of configuration options with regards to the internal and external applicant types which you should have active or inactive. These options should be properly set prior to the development of programs, applicant parameters, and process elements so that the options available for them reflect the types of applicants that you will have on your site.
1.) Activating/Deactivating the proper applicant types
To know which should be turned on or off, you should first familiarize yourself with what is referred to as Internal and External:
Internal Applicants: These are the applicants that identify themselves as registered with your institution/office.
In the case of a university office, these would be the students of the university.
External Applicants: These are the applicants that identify themselves as belonging to an outside institution/office.
In the case of a university office, it would be the students of another university that are applying to a program through the office, but are not attending the office's university.
In the case of a study abroad program provider, this would be all their applicants since their office does not have 'registered attendees'.
Before you begin implementing programs, process elements, or parameters, determine which of these applicant types need to be enabled and/or disabled on your site.
The applicant types are enabled/disabled on the Settings > System Features page. Internal/External Outgoing applicant types are turned on and off at the top of the page just under the 'Applicant and Application Process:' heading.
2.) Setting the proper environment setting for Secure Campus Login
There is a configuration option which will enable/disable certain behaviors in your site with regards to login requests. This setting is on the Maintenance > Environment Settings page at the top. It is called 'Enable SCL Authentication'. SCL stands for Secure Campus Login
Note: If your site is a SaaS account or you are a hosted client, your site admin will not have access to this maintenance tool. This setting can be changed on your site on request through the support case system.
The 'Enable SCL Authentication' setting is used to determine how the integrated users will be accessing your site. When this setting is enabled, the integrated users will be routed to the login page after identifying themselves as having SCL credentials. If your site has a secure campus login and information system integration installed, this setting should be set to 'Yes'.
When the SCL authentication setting is set to 'Yes', the applicants that identify themselves as having an SCL username and password will not be required to request login credentials and will have their user information drawn from the information system after authentication through your secure campus login portal.
There are two circumstances under which you should have the 'Enable SCL Authentication' configured to 'No':
- Your site is not integrating with a secure campus login authentication system
- Your site will be integrating with a secure campus login authentication system, but it has not yet been installed
When the 'Enable SCL Authentication' is set to 'No', all applicants (whether they identify themselves as internal or external) will always be asked if they have received login credentials via email and be routed to the form for requesting them. However, it will create them as 'internal' or 'external' based whether or not they are registered with your institution.
If your site is one that will be integrating with a secure campus login, but it has not yet been installed, you should have the setting on 'No', but when the integration is completed, it should be switched over to 'Yes'. This way, the internal processes can be tested using software-issued login credentials until the integrations are ready to be installed.
Changing an external applicant to an internal applicant
In some cases, your office may require that your external applicants register through your institution and obtain a secure campus login and information system record. After this process has been completed, the external applicant fits the description of an internal applicant, and your office may desire to change the user to login through the SCL system as well as link student parameters to the available information in your SIS.
This can be done through the Maintenance > Edit User tool through the following process:
- Go to Maintenance > Edit User and search for the applicant you wish to change
- Change the user's 'Integrated User Flag' to 'Yes'
- Change the User Name to the UUUID that is used for your site for this user. Note: This might not be the actual username that the applicant uses when logging in. Check with your site's SCL integration settings to find the proper field in the applicant's SIS record to use for the User Name.
- Click the 'Next' button
After doing this, you should notify the applicant that instead of logging in using the previously used login credentials, s/he should login using the username and password that has been configured through your institution's IT Dept.
The SIS data for this applicant will be imported from your SIS the next time the SISRefresh routine is executed through the scheduled task. This assumes that the applicant has an active application in the system.
Before switching an applicant to the internal user type, it is important to decide whether or not it is truly necessary to make this change in the user record. If you will not need to have the SIS data imported for this applicant, there is no tangible benefit to making this type of change in the record other than their ability to login using your SCL system.