Sessions leveraging JEA require some authoring before they can be used. There are at least two components needed: a session configuration and at least one role capability definition.

The first and most important part of authoring a new endpoint is to identify the requirements of your roles. For many operations people, this even includes defining what roles exist in the first place. One such role could be first-level user support that needs to reset user passwords and set NTFS permissions on specific paths. Maybe members of this role are also allowed to see the status of certain services, for example, the spooler service on a print server:

# Possible cmdlets for first-level user admin

# Modify user passwords only in specific search bases
$account = Get-ADUser -SearchBase 'OU=Users,OU=DepartmentXY,DC=contoso,DC=com' -SearchScope Subtree -Identity neilgaiman

$password = Read-Host -AsSecureString -Prompt 'Password please'
Set-ADAccountPassword -NewPassword $password -Identity $account

# Modify group memberships only for specific OUs
Add-AdGroupMember -Identity "CN=groupName,OU=DepartmentXY,DC=contoso,DC=com" -Members account1,account2,account3
Get-AdGroupMember -Identity "CN=groupName,OU=DepartmentXY,DC=contoso,DC=com"

# Modify permissions only in certain paths
Add-NTFSAccess -Path \namespacegroupsharegroupfolder -Account contosoGroupAccount

# Get service status
Get-Service -Name spooler

The next step is to identify which cmdlets are needed to accomplish the tasks you identified. Since JEA will not restrict the UI components, your users will need to use PowerShell to accomplish any task. If you are using UI components that can be configured to use endpoint configurations, you could restrict them to their set of cmdlets:

# Hiding complexity
function Get-DepartmentAdUser
{
    [CmdletBinding()]
    param
    (
        $DepartmentName,

        $UserName
    )

    Get-ADUser -SearchBase "OU=Users,OU=$DepartmentName,DC=contoso,DC=com" -SearchScope Subtree -Identity $UserName
}

If you have identified cmdlets that might be useful to your users, but you want to hide their complexity or you require additional setup to be done before these cmdlets are called, you might consider wrapping them in functions that your users can use. Those functions can internally call whatever PowerShell cmdlets, .NET functions, and APIs you need. The user will only see one cmdlet, and not what happens in the background.