Edit

Automation Toolkit Crate

If you’re new to Crates, read through our introductory Crate documentation here. Find the Crate in our Crate Marketplace.

What does the Automation Toolkit Crate do?

Our Automation Toolkit Crate enhances system efficiency by offering prebuilt function-based subworkflows designed for commonly used tasks. With a focus on reducing time to value, these workflows empower users to quickly configure and execute complex automations without starting from scratch.

How the Crate works

This Crate is a little different from most of our other Crates. It contains a collection of subworkflows you can use in building your own workflows rather than a fully-executable workflow that achieves a goal right after unpacking.

This Crate leverages powerful native integrations within Rewst to ensure seamless connectivity with various platforms including Microsoft Graph, Microsoft Exchange Online, PSA systems, and RMM providers.

  • Configure necessary integrations and set organizational variables for your PSA software, Microsoft Graph or Cloud Service Provider, and RMM provider.

  • Link subworkflows from this Crate to your existing automations.

  • Combine modular subworkflows to create streamlined, efficient processes.

  • Enhance operational efficiency by automating repetitive tasks, improving accuracy, and reducing manual intervention.

Unpack the Automation Toolkit Crate

  1. Navigate to Crates > Crate Marketplace in the left side menu Rewst platform.

  2. Search for Automation Toolkit.​

  3. Click on the Crate tile to begin unpacking.

  4. Click Unpack Crate.

  5. Click Continue.

  6. Click Unpack.

  7. After you unpack the Crate, all the subworkflows it contains will now appear in the left side Action menu of your Workflow Builder for use in any workflow in the organization where the Crate was unpacked. Search for the name of your desired subworkflow, or scroll through the available list under the Workflows section of the Action menu.

Subworkflow breakdowns

When you unpack the Crate and click into its workflow, you'll see the below screen with all the unpacked subworkflows on the Workflow Builder Canvas. Click on any of the subworkflows to open that individual subworkflow in a new window and Workflow Builder. The Useful Transforms column contains transform actions that are already available in your Workflow Builder's action list. They're listed here as a reminder for their usefulness with this Crate's subworkflows. See our documentation on transform actions for explanations and examples using these actions.

The Workflow Builder canvas for the unpacked Crate

Click any subworkflow name below to expand and view the subworkflow's full process breakdown.

[REWST - PROCESS] PSA: Create Ticket

  1. BEGIN task initiates the workflow execution and immediately transitions to the next step.

  2. set_variables task performs initial variable setup and determines the PSA provider by checking if a PSA value was provided in the context, otherwise it uses the organization's default PSA from ORG.VARIABLES.default_psa.

  3. determine_provider task acts as a routing decision point that examines the PSA provider and sets the appropriate company ID based on the provider type, then routes the workflow to the corresponding PSA-specific ticket creation task based on these conditions:

    • If PSA is cw_manage, it routes to cwpsa_create_ticket task

    • If PSA is datto_psa, it routes to datto_psa_create_ticket task

    • If PSA is halo_psa, it routes to halo_psa_create_ticket task

    • If PSA is kaseya_bms, it routes to kaseya_bms_create_ticket task

    • If PSA is servicenow, it routes to service_now_create_ticket task

    • If PSA is freshdesk, it routes to freshdesk_create_ticket task

    • If PSA is superops, it routes to superops_create_ticket task

    • If PSA is mail_only, it skips ticket creation and goes directly to END task

  4. The appropriate PSA-specific ticket creation task executes based on the routing decision:

    • cwpsa_create_ticket task creates tickets in ConnectWise PSA

    • datto_psa_create_ticket task creates tickets in Datto PSA

    • halo_psa_create_ticket task creates tickets in Halo PSA

    • kaseya_bms_create_ticket task creates tickets in Kaseya BMS

    • service_now_create_ticket task creates tickets in ServiceNow

    • freshdesk_create_ticket task creates tickets in Freshdesk

    • superops_create_ticket task creates tickets in SuperOps

  5. Each PSA-specific task has two possible outcomes:

    • On success, it transitions to format_output task

    • On failure, it transitions to action_failure task

  6. format_output task processes successful ticket creation results and publishes the ticket ID and ticket data to the workflow context, then transitions to END task.

  7. action_failure task handles any failures from the PSA-specific tasks by setting the success flag to false, then transitions to END task.

  8. END task compiles the final automation log with status codes, success indicators, data, errors, warnings, and all task entries, completing the workflow execution.

[REWST - PROCESS] PSA: Update Ticket

  1. choose_psa task acts as the initial routing decision point that examines the PSA provider and routes the workflow to the appropriate PSA-specific update task based on these conditions:

    • If PSA is mail_only, the workflow ends without processing

    • If PSA is cw_manage, it routes to check_time_contact task for ConnectWise PSA

    • If PSA is datto_psa, it routes to update_datto_ticket task for Datto PSA

    • If PSA is halo_psa, it routes to update_halo_ticket task for Halo PSA

    • If PSA is kaseya_bms, it routes to update_kaseya_ticket task for Kaseya BMS

    • If PSA is freshdesk, it routes to update_freshdesk_ticket task for Freshdesk

    • If PSA is servicenow, it routes to update_servicenow_ticket task for ServiceNow

  2. check_time_contact task determines if a technician ID is available for ConnectWise PSA operations:

    • If cwm_tech_id is defined, it proceeds to noop task

    • If cwm_tech_id is not defined, it routes to get_service_ticket task

  3. get_service_ticket task retrieves the current ticket information and sets the technician ID:

    • If psa_default_tech_id organization variable is defined, it uses that value

    • If the ticket owner ID is available, it uses the ticket owner's ID

    • Then proceeds to noop task

  4. noop task serves as a pass-through and transitions to calculate_ticket_time task.

  5. calculate_ticket_time task determines the time to be logged on the ticket:

    • If organization variables indicate no ticket time should be logged, it sets ticket_hours to 0

    • Otherwise, it calculates ticket_hours from work_minutes divided by 60

    • Then proceeds to check_status_update task

  6. check_status_update task determines the next action based on ticket status requirements:

    • If set_ticket_status is defined, it routes to update_service_ticket task

    • Otherwise, it proceeds to check_ticket_hours task

  7. update_service_ticket task updates the ticket status and transitions to check_ticket_hours task on both success and failure.

  8. check_ticket_hours task evaluates the time entry requirements:

    • If ticket_hours equals 0, it routes to note_type task

    • Otherwise, it proceeds to check_time_entry_org_var task

  9. check_time_entry_org_var task checks organization-specific time entry settings:

    • If time_entry_ticket_status organization variable is defined, it routes to update_service_ticket task

    • Otherwise, it proceeds to add_time_entry task

  10. add_time_entry task creates a time entry on the ticket and transitions to completing_workflow task on both success and failure.

  11. completing_workflow task determines if workflow completion actions are needed:

    • If set_ticket_status or complete_workflow is defined, it routes to core_delay_workflow_for_period task

    • Otherwise, it proceeds to FINISH_TICKET_UPDATE task

  12. core_delay_workflow_for_period task introduces a delay before final updates and transitions to update_ticket_qc task.

  13. update_ticket_qc task performs final ticket quality control updates and transitions to FINISH_TICKET_UPDATE task on both success and failure.

  14. note_type task determines what type of note to add based on available context:

    • If internal_note is provided, it routes to add_internal_note task

    • If external_note is provided, it routes to check_if_should_be_internal task for external notes

    • If resolution_note is provided, it routes to check_if_should_be_internal task for resolution notes

    • If status updates are required, it routes to core_delay_workflow_for_period task

  15. The PSA-specific update tasks handle ticket updates for their respective platforms: a. update_datto_ticket task updates tickets in Datto PSA b. update_halo_ticket task updates tickets in Halo PSA c. update_kaseya_ticket task updates tickets in Kaseya BMS d. update_freshdesk_ticket task updates tickets in Freshdesk e. update_servicenow_ticket task updates tickets in ServiceNow

  16. FINISH_TICKET_UPDATE task serves as the final completion point for the workflow.

Rewst: Send Email with Attachment

  1. The workflow begins by accepting input parameters including the recipient email addresses array, subject line, sender GUID, attachment details including name, type, and encoded contents, message contents, and failover configuration options.

  2. The check_sendas_field task validates the provided sender GUID to ensure it contains a valid user identifier for email sending purposes.

  3. The microsoft_graph_get_user task retrieves user information from Microsoft Graph API using the provided sender GUID to verify the user exists and has proper permissions for sending emails.

  4. If the user lookup is successful, the workflow proceeds to the Send_Email task which attempts to send the email with attachment through Microsoft Graph API using the impersonated user account.

  5. If the Microsoft Graph send method fails or if the use_failover option is enabled and set to true, the workflow transitions to the core_sendmail task as a backup method for sending the email.

  6. The user_not_found task serves as a no-operation fallback that handles cases where the specified sender user cannot be located in the Microsoft 365 tenant.

  7. Throughout the process, the workflow handles attachment processing by accepting base64 encoded file contents along with the attachment name and type specifications.

  8. The workflow includes built-in error handling for failed deliveries, missing user accounts, and authentication issues that may occur during the email sending process.

  9. Upon completion, the workflow generates standardized automation logs documenting the execution results and any errors encountered during the process.

  10. The workflow outputs a dictionary object containing a success key with a boolean value indicating whether the email was successfully sent or not.

  11. If attachments are provided, they are properly formatted and included with the email regardless of which sending method is ultimately used.

  12. The workflow concludes by returning the final status and any relevant error messages or success confirmations to the calling automation or user.

  13. All communication tasks are properly categorized and logged for audit purposes and troubleshooting future email delivery issues.

Upload CSV To Ticket

  1. The workflow begins with the START task which uses the noop action to accept input parameters including the PSA system type, CSV file content, title, ticket ID, and attachment name, then determines which PSA system to use by checking the provided PSA parameter or defaulting to the organization's default PSA variable.

  2. The select_psa task uses the noop action to evaluate the PSA system type and creates conditional transitions to route the workflow to the appropriate PSA-specific upload task based on whether the system is ConnectWise PSA, Datto PSA, Halo PSA, or other supported systems.

  3. If the PSA is ConnectWise PSA, the workflow transitions to the cw_psa_upload_csv_to_ticket task which executes the [REWST - TASK] PSA-CWM: Upload Document to Ticket action to upload the CSV file as an attachment to the specified ConnectWise Manage ticket.

  4. If the PSA is Datto PSA, the workflow transitions to the datto_upload_csv_to_ticket task which uses the Datto PSA API Request action to make an authenticated API call to upload the CSV file to the specified Datto Autotask ticket.

  5. If the PSA is Halo PSA, the workflow transitions to the halo_psa_add_or_update_attachments task which executes the Add or Update Attachments action to attach the CSV file to the specified HaloPSA ticket in Base64 format.

  6. For other PSA systems like Kaseya BMS, ServiceNow, or Freshdesk, the workflow transitions to the core_create_webhook task which uses the Create a one-off webhook, for intra-workflow signaling action to handle the upload process.

  7. After the PSA-specific upload task completes successfully, the workflow transitions to the update_ticket_internal_note task which executes the [REWST - TASK] Update Ticket Internal Note action to add an internal note to the ticket documenting the CSV file upload.

  8. If the ticket note update succeeds, the workflow transitions to the SUCCESS task which uses the noop action to publish a success value of true and prepares the workflow for completion.

  9. If any task fails during the process, the workflow transitions to the FAILED task which uses the noop action to publish a success value of false and logs the failure for troubleshooting purposes.

  10. Both the SUCCESS and FAILED tasks transition to the END task which uses the noop action to compile the automation log by collecting all task results, status codes, and error messages from throughout the workflow execution.

  11. The END task generates a comprehensive automation log that includes the overall status code, success indicator, collected data, any errors or warnings encountered, and detailed entries from each executed task.

  12. The workflow concludes by outputting the standardized automation log containing all execution details, making it easy for MSPs to track the success or failure of CSV file uploads across different PSA platforms.

  13. Throughout the entire process, the workflow maintains consistent error handling and logging practices regardless of which PSA system is being used for the CSV upload operation.

[REWST - TASK] Send Message

  1. The workflow begins with the BEGIN task which uses the noop action to accept input parameters including the chat type, message content, and platform-specific configuration details for sending messages across different communication channels.

  2. The change_messaging_platform task uses the noop action to evaluate the chat_type parameter and creates conditional transitions to route the workflow to the appropriate messaging platform based on whether the type is Slack, Discord, SMS, or email.

  3. If the chat_type is "slack", the workflow transitions to the slack_chat_post_message task which uses the Sends a message to a channel action to post the message to the specified Slack channel using the Slack integration.

  4. If the chat_type is "discord", the workflow transitions to the discord_create_channel_message task which uses the Create a message in a channel action to send the message to the specified Discord channel using the Discord integration.

  5. If the chat_type is "sms", the workflow transitions to the core_send_sms task which uses the Send a text message action to deliver the message as an SMS to the specified phone number using the core SMS functionality.

  6. If the chat_type is "email", the workflow transitions to the core_sendmail task which uses the This sends an email action to deliver the message as an email to the specified recipient using the core email functionality.

  7. If any of the messaging tasks complete successfully, the workflow transitions directly to the END task to finalize the process and generate the automation log.

  8. If any of the messaging tasks fail, the workflow transitions to the action_failure task which uses the noop action to handle the failure and log the appropriate error message for the specific messaging platform that failed.

  9. The action_failure task publishes a log entry with a status code of 2000 indicating a failure and includes details about which specific messaging task failed to complete.

  10. After handling any failures, the action_failure task transitions to the END task to ensure the workflow completes properly regardless of success or failure.

  11. The END task uses the noop action to compile the automation log by collecting all task results, status codes, and error messages from throughout the workflow execution.

  12. The END task generates a comprehensive automation log that includes the overall status code, success indicator, collected data, any errors or warnings encountered, and detailed entries from each executed task.

  13. The workflow concludes by outputting the standardized automation log containing all execution details, making it easy to track the success or failure of message delivery across different communication platforms.

User Onboarding: Create User

  1. The workflow begins at the START task which initializes valid identity provider options and sets the success flag to true.

  2. The evaluate_idp task determines the appropriate identity provider configuration based on organization variables and input parameters, evaluating options like Azure AD, on-premises, hybrid configurations, JumpCloud, or Secure Cloud.

  3. The valid_idp_check task validates that the determined identity provider is supported and configured correctly for the organization.

  4. The select_identity_provider task routes the workflow to the appropriate user creation path based on the identity provider configuration determined in the previous steps.

  5. Depending on the identity provider, one of several user creation paths executes:

    • For Azure AD: The create_azure_ad_user action creates the user in Microsoft 365

    • For on-premises: The create_on_prem_user action creates the user in Active Directory

    • For JumpCloud: The jump_cloud_create_user action creates the user in JumpCloud

    • For Secure Cloud: The create_secure_cloud_user action creates the user in the secure cloud environment

    • For hybrid configurations: Multiple user creation actions may execute sequentially

  6. After user creation, the check_user_created task verifies that the user was successfully created and handles any creation errors.

  7. If the user creation was successful, the check_exist task determines if the user already existed and handles duplicate user scenarios appropriately.

  8. The add_to_on_prem_groups action adds the newly created user to the appropriate Active Directory security groups based on their role and permissions.

  9. For JumpCloud environments, the add_to_jumpcloud_groups action assigns the user to the correct JumpCloud user groups.

  10. The jumpcloud_complete task determines if additional synchronization steps are needed based on organization configuration.

  11. If Active Directory synchronization is required, the run_ad_sync action triggers synchronization between on-premises Active Directory and Azure AD.

  12. The delay_for_ad_sync task pauses the workflow to allow time for the synchronization process to complete.

  13. The Wait for AD to sync to Azure task provides additional delay with retry logic to ensure the user appears in Azure AD.

  14. The check_for_azure_ad_user action verifies that the user has successfully synchronized to Azure AD and retrieves the user's Azure AD object ID.

  15. The get_ids task collects both the on-premises user SID and Azure AD user ID for future reference.

  16. The check_if_failed task evaluates the overall success of both on-premises and cloud user creation processes.

  17. The check_document_password task determines if the user's password should be documented in a support ticket based on organization policies.

  18. If password documentation is required, the document_password_in_ticket action creates or updates a support ticket with the user's temporary password information.

  19. The workflow concludes at the END task, which compiles an automation log with the status of all executed tasks and publishes the final workflow results.

  20. If any critical errors occur during the process, the failure_catch task handles the error condition and routes to the failed_to_create_user or user_already_exists tasks as appropriate before ending the workflow.

[PROC] User: Change Password

  1. The workflow begins at the START task which initializes valid identity provider options for password changes including on-premises, hybrid no sync, Azure AD, and on-premises only configurations.

  2. The validate_vars task verifies that required variables are present including the default PSA configuration and the new password value before proceeding with the password change process.

  3. The process_inputs task determines the appropriate identity provider configuration based on organization variables, evaluating whether the environment uses Azure AD, on-premises Active Directory, hybrid configurations, or on-premises only setups.

  4. The valid_idp_check task validates that the determined identity provider is supported and properly configured for password change operations within the organization.

  5. The check_on_prem task determines if an on-premises password reset is required based on the identity provider configuration and verifies that the required RMM tool is configured for executing the password change.

  6. If on-premises password change is needed, the change_on_prem_password action executes the password change operation against the Active Directory domain controller using the configured RMM tool.

  7. The check_ad_sync task evaluates whether Active Directory synchronization to Azure AD is required based on the identity provider configuration to ensure password changes propagate to cloud services.

  8. If AD sync is required, the run_ad_sync action triggers the synchronization process between on-premises Active Directory and Azure AD to replicate the password change to the cloud environment.

  9. The check_azure task determines if an Azure AD password reset is needed for hybrid configurations or Azure AD-only environments where the password must be changed directly in the cloud.

  10. If Azure password change is required, the change_entra_passwordaction executes the password change operation directly against the Azure AD tenant using Microsoft Graph API calls.

  11. The workflow_end task evaluates the overall success of the password change operations and determines the appropriate next steps based on ticketing configuration and workflow results.

  12. The ticketing task determines whether to create a new support ticket or update an existing ticket based on the presence of a ticket ID in the workflow inputs.

  13. If a ticket ID is provided, the update_ticket action adds notes about the password change operation to the existing support ticket with details about the success or failure of the operation.

  14. If no ticket ID is provided, the create_ticket action creates a new support ticket documenting the password change request and its outcome for tracking purposes.

  15. If PSA ticketing operations fail, the psa_action_failure task handles the error condition and prepares to send notification emails as a fallback communication method.

  16. The email_fallback task checks if fallback email notification is configured and prepares to send email notifications when ticketing systems are unavailable or fail.

  17. If email fallback is configured, the failure_backup action sends an email notification with details about the password change operation and any issues encountered during execution.

  18. If no PSA or email is configured, the no_psa_or_email_configured task handles the scenario where no notification methods are available for reporting workflow results.

  19. If ticketing is disabled, the no_ticketing task bypasses all ticket creation and update operations and proceeds directly to workflow completion.

  20. The workflow concludes at the END task which compiles a comprehensive automation log with the status of all executed tasks and publishes the final workflow results.

  21. If any critical errors occur during the process, the failure_catch task handles the error condition, sets the success flag to false, and ensures proper error logging before workflow completion.

[REWST - TASK] M365: Invalidate User Sessions

  1. The workflow begins at the START task which initializes the session invalidation process for a Microsoft 365 user account.

  2. The check_inputs task validates that the required user ID parameter has been provided as input to ensure the workflow can properly identify which user's sessions need to be invalidated.

  3. If the user ID input is missing, the workflow routes to the failure_catch task which handles the error condition by setting the success flag to false and logging the missing input error.

  4. If the user ID input is provided, the invalidate_sessions action executes a Microsoft Graph API request to revoke all active authentication sessions for the specified user account across all devices and applications.

  5. Upon successful session invalidation, the workflow sets the success flag to true and logs a confirmation message indicating that the user's sessions have been successfully invalidated.

  6. If the session invalidation operation fails, the workflow routes to the failure_catch task which handles the error condition and logs the failure to invalidate sessions.

  7. The workflow concludes at the END task which compiles an automation log with the status of all executed tasks and publishes the final workflow results including success status and any error or warning messages.

M365: Add User to Security Group

  1. The workflow begins with the add_user_to_group action which executes a Microsoft Graph API request to add the specified user to the designated Microsoft 365 security group.

  2. If the user is successfully added to the security group, the workflow completes successfully without any additional processing steps.

  3. If the add_user_to_group action fails, the workflow proceeds to the check_error task which evaluates the specific error message returned from the Microsoft Graph API to determine the cause of the failure.

  4. The check_error task examines whether the error message contains "One or more added object references already exist" which indicates that the user is already a member of the specified security group.

  5. If the error indicates that the user is already a member of the group, the workflow routes to the member_already_exists task which handles this scenario as a non-critical condition since the desired end state has already been achieved.

  6. The member_already_exists task completes the workflow successfully, treating the "already exists" condition as a successful operation since the user has the required group membership.

  7. The workflow concludes after either successfully adding the user to the group or confirming that the user already has the required group membership.

365/On-Prem: Disable User Account

  1. The workflow begins at the START task which initializes valid identity provider options including on-premises, hybrid no sync, Azure AD, and on-premises only configurations.

  2. The evaluate_idp task determines the appropriate identity provider configuration based on organization variables, evaluating whether the environment uses Azure AD, on-premises Active Directory, hybrid configurations, or on-premises only setups.

  3. The valid_idp_check task validates that the determined identity provider is supported and properly configured for user account disabling operations within the organization.

  4. The validate_inputs task verifies that at least one required user identifier has been provided, either an Azure AD user ID or an on-premises user ID, to ensure the workflow can properly identify which user account needs to be disabled.

  5. The check_aad task determines if an Azure AD user disable operation is required based on the presence of an Azure AD user ID and the identity provider configuration being hybrid no sync or Azure AD only.

  6. If Azure AD disable is needed, the disable_aad_user action executes a Microsoft Graph API request to disable the user account in Azure AD, preventing the user from signing in to cloud services.

  7. The check_on_prem task evaluates whether an on-premises Active Directory disable operation is required based on the presence of an on-premises user ID and the identity provider configuration supporting on-premises accounts.

  8. If on-premises disable is needed, the disable_on_prem action executes the user account disable operation against the Active Directory domain controller using the configured management tools.

  9. Upon successful completion of either or both disable operations, the workflow sets the success flag to true and logs confirmation messages indicating which user accounts have been successfully disabled.

  10. If any disable operation fails, the workflow routes to the failure_catchtask which handles the error condition by setting the success flag to false and logging the specific failure details.

  11. The workflow concludes at the END task which compiles an automation log with the status of all executed tasks and publishes the final workflow results including success status and any error or warning messages.

[REWST - TASK] Automate: Run Powershell

  1. The workflow begins at the START task which initializes the PowerShell script execution process for ConnectWise Automate managed devices.

  2. The check_script_was_provided task validates that a PowerShell script template has been provided as input to ensure the workflow has the necessary script content to execute.

  3. The check_cwa_mapping task verifies that the organization is properly mapped to a ConnectWise Automate client by checking for the presence of the CWA client ID in the organization variables.

  4. The resolve_device task determines the target device for script execution by evaluating whether a device ID, device name, or organization preferred domain controller has been provided as input.

  5. If a device ID is provided, the get_automate_devices action retrieves the specific device information from ConnectWise Automate using the provided device ID.

  6. If a device name is provided, the get_automate_devices action searches for devices matching the specified name and filters the results to find an exact match.

  7. If no specific device is provided, the get_automate_devices action searches for domain controllers within the client and selects the one with the highest ID as the target device.

  8. The Select Highest ID DC task processes the list of domain controllers and selects the device with the highest computer ID, which is typically the newest operating system version.

  9. The check_device_returned task validates that exactly one matching device was found and extracts the device ID for subsequent operations.

  10. The device_online_check task verifies that the target device is currently online and available for script execution.

  11. The check_fastalk task determines if the device already has FastTalk enabled, which allows for faster communication between Automate and the managed device.

  12. If FastTalk is not enabled, the set_fastalk action attempts to enable FastTalk on the target device to improve script execution performance.

  13. The start_webhooks task prepares the webhook infrastructure needed to receive results from the PowerShell script execution.

  14. The generate_webhooks action creates the necessary webhook endpoints for posting script results and retrieving execution status.

  15. The run_powershell action executes the provided PowerShell script on the target device through ConnectWise Automate's command execution system.

  16. The await_script_results action waits for the script execution to complete and receives the results through the configured webhook endpoint.

  17. Upon successful completion, the workflow publishes the script output and logs the successful execution status.

  18. If any step fails during the process, the failure_catch task handles the error condition and logs appropriate error messages with diagnostic information.

  19. The workflow concludes at the END task which compiles an automation log with the status of all executed tasks and publishes the final workflow results including the PowerShell script output.

Resolve Graph SKU to Offername

  1. The workflow begins at the START task which initializes the process for resolving a Microsoft Graph SKU ID to its corresponding offer name.

  2. The get_tenant_subscriptions action retrieves all available subscriptions from the Microsoft 365 tenant using Microsoft Graph API to obtain license information.

  3. Upon successful retrieval of tenant subscriptions, the workflow filters the results to find subscriptions that match the provided SKU ID and stores the filtered licenses for further processing.

  4. The check_if_found task evaluates whether any matching licenses were found in the filtered results from the tenant subscription query.

  5. If a matching license is found, the workflow selects the first matching license from the filtered results and logs the successful match with the license data.

  6. The json_parse_licence_lookup task processes a template containing Microsoft license information and parses it as JSON to create a comprehensive lookup table of all Microsoft licenses.

  7. The workflow filters the Microsoft license lookup table to find the entry that matches the provided SKU ID and extracts the corresponding product display name as the offer name.

  8. If no matching license is found during the subscription query, the workflow routes to the no_match_found task which logs the failure to match the license.

  9. If the Microsoft Graph API call fails during the subscription retrieval, the workflow routes to the graph_failure task which logs the API failure with appropriate error details.

  10. The workflow concludes at the END task which compiles an automation log with the status of all executed tasks and publishes the final results including the resolved offer name, success status, and any error or warning messages.

[TASK] M365: Remove Licenses

  1. The workflow begins with the START task which uses the noop action to initialize the workflow execution.

  2. The workflow then executes the validate_inputs task which uses the noop action to verify that the required Azure Active Directory user ID has been provided as input.

  3. Next, the get_assigned_licenses task uses the Get User action to retrieve the user's current license assignments and profile information from Microsoft Graph API.

  4. The workflow then runs the get_friendly_names task which calls the M365: Get User Licenses With Friendly Names action to convert the technical license SKU IDs into human-readable license names.

  5. The check_license_count task uses the noop action to determine if the user has any licenses assigned that can be removed, creating a list of license SKU IDs to process.

  6. If licenses are found, the workflow proceeds to the Get-MailboxStatistics task which uses the InvokeCommand action to retrieve the user's mailbox size information from Exchange Online.

  7. The calculate_quota_percent task uses the noop action to parse the mailbox statistics and extract the total mailbox size in bytes for comparison purposes.

  8. The Branch_MailBox_Over_50GB task uses the noop action to check if the user's mailbox exceeds 50 gigabytes, which would prevent license removal to avoid data loss.

  9. If the mailbox is under 50 gigabytes, the remove_licenses task uses the Assign License to User action to remove all assigned licenses from the user account.

  10. If any step fails or the mailbox is too large, the failure_catch task uses the noop action to handle the error condition and set the success flag to false.

  11. Finally, the END task uses the noop action to compile a comprehensive automation log that includes the status codes, success indicators, removed licenses list, and detailed logging information from each step of the process.

M365: Get User Licenses With Friendly Names

  1. The workflow begins with the List_Users task which uses the Graph API Request action to retrieve a list of Microsoft 365 users from the Microsoft Graph API endpoint.

  2. The List_Users task filters the user data to include only users who have sign-in activity, have assigned licenses, have enabled accounts, and do not have "leaver" in their display name.

  3. The workflow then executes the get_user_licenses task which uses the Graph API Request action to retrieve the specific license information for each user.

  4. The get_user_licenses task processes the license data and extracts the SKU part numbers from each user's assigned licenses into a list format.

  5. Next, the get_M365_lookup_table task uses the noop action to retrieve a predefined template containing the Microsoft 365 license lookup table that maps license SKU IDs to friendly display names.

  6. The map_license task uses the noop action to cross-reference the user's license SKU IDs with the lookup table to find the corresponding friendly product display names.

  7. Finally, the unique_licenses task uses the noop action to create a deduplicated list of unique licenses with their friendly names and compile all license information into a comprehensive output.

  8. The workflow publishes two key outputs: a "licenses" list containing the unique friendly license names and an "all_licence_info" object containing detailed license information for all processed user

[Rewst - TASK] EXO Set Permissions

  1. The workflow begins with the START task which uses the noop action to initialize the workflow execution.

  2. The workflow then executes the check_automap_shared_mailbox task which uses the noop action to determine whether the shared mailbox should be automatically mapped to the recipient's Outlook profile or not.

  3. If automap is disabled, the workflow proceeds to the full_access_no_automap task which uses the InvokeCommand action to grant full access permissions to the specified mailbox without enabling automatic mapping in Outlook.

  4. If automap is enabled, the workflow executes the full_access task which uses the InvokeCommand action to grant full access permissions to the specified mailbox with automatic mapping enabled in Outlook.

  5. After granting full access permissions, the workflow continues to the check_add_send_as task which uses the noop action to evaluate whether Send As permissions should also be granted to the recipient.

  6. If Send As permissions are required, the workflow executes the add_sendas_access task which uses the InvokeCommand action to grant Send As permissions on the specified mailbox to the recipient.

  7. If Send As permissions are not required, the workflow skips the Send As step and proceeds directly to the update_output task which uses the noop action to set the success flag to true.

  8. If any of the permission-setting tasks fail, the workflow redirects to the failed task which uses the noop action to set the success flag to false and log the failure details.

  9. Finally, the workflow concludes with the End task which uses the noopaction to compile a comprehensive automation log that includes status codes, success indicators, error messages, and detailed logging information from each step of the permission-setting process.

[REWST - TASK] Hide From Gal

  1. The workflow begins with the START task which uses the noop action to initialize the workflow execution.

  2. The workflow then executes the process_inputs task which uses the noop action to determine the identity provider configuration by evaluating organization variables and input parameters to identify whether the environment is Azure AD, on-premises, hybrid, or on-premises only.

  3. Next, the check_on_prem task uses the noop action to evaluate if on-premises Active Directory operations are needed based on the identity provider configuration and whether a default RMM is configured.

  4. If on-premises operations are required, the workflow proceeds to the hide_from_gal_on_prem task which uses the Run Powershell via RMMaction to execute PowerShell commands through the RMM to hide the user from the Global Address List in on-premises Active Directory.

  5. After completing on-premises operations, the workflow continues to the check_ad_sync task which uses the noop action to determine if Active Directory synchronization is needed based on the identity provider configuration.

  6. If AD synchronization is required, the workflow executes the run_ad_sync task which uses the Run Powershell via RMM action to trigger Active Directory Connect synchronization to replicate changes to Azure AD.

  7. Following synchronization operations, the workflow proceeds to the check_azure task which uses the noop action to evaluate if Azure AD operations are needed based on the identity provider configuration.

  8. If Azure AD operations are required, the workflow executes the hide_from_gal_aad task which uses the InvokeCommand action to hide the user from the Global Address List in Azure Active Directory using PowerShell commands.

  9. If any step fails or encounters an error, the workflow redirects to the failed task which uses the noop action to set the success flag to false and log the failure details.

  10. Finally, the workflow concludes with the END task which uses the noop action to compile a comprehensive automation log that includes status codes, success indicators, error messages, and detailed logging information from each step of the hide from GAL process.

[REWST - TASK] Forward Mail

  1. The workflow begins with the START task which uses the noop action to initialize the workflow execution.

  2. The workflow then executes the check_store_in_mailbox task which uses the noop action to evaluate whether mail forwarding should be configured to store copies of forwarded messages in the original mailbox or forward without storing copies.

  3. If mail forwarding with storage is required, the workflow proceeds to the forward_mail_and_store task which uses the InvokeCommandaction to configure Exchange Online mail forwarding that forwards messages to the specified recipient while keeping copies in the original mailbox.

  4. If mail forwarding without storage is required, the workflow executes the forward_mail_no_store task which uses the InvokeCommandaction to configure Exchange Online mail forwarding that forwards messages to the specified recipient without keeping copies in the original mailbox.

  5. After successfully configuring mail forwarding, the workflow continues to the set_output_sucess task which uses the noop action to set the success flag to true indicating that the mail forwarding configuration was completed successfully.

  6. If any of the mail forwarding configuration tasks fail, the workflow redirects to the failed task which uses the noop action to set the success flag to false and log the failure details.

  7. Finally, the workflow concludes with the END task which uses the noop action to compile a comprehensive automation log that includes status codes, success indicators, error messages, and detailed logging information from each step of the mail forwarding configuration process.

[CRATE] Rewst: Automation Toolkit

  1. The workflow begins with multiple category sections that serve as organizational containers for different types of automation tasks, including Account_Manipulation, Customer_Communication, Helper_Utilities, M365_Exchange, M365_Licensing, Run_PS, and Useful_Transforms tasks which all use the noop action to provide structural organization.

  2. The disable_account task uses the 365/On-Prem: Disable User Account action to disable user accounts across both Azure AD and on-premises Active Directory environments with comprehensive logging of the operation results.

  3. The change_password task uses the Run Powershell via RMM action to execute password change operations through remote management tools with detailed success and failure logging.

  4. The create_user task uses the M365: Create User action to create new user accounts and publishes key identifiers including Azure AD user ID, user object details, and on-premises user SID for subsequent workflow operations.

  5. The update_psa_ticket task uses the Update PSA Ticket action to modify Professional Services Automation tickets with automation results and status updates.

  6. Multiple Microsoft 365 and Exchange-related tasks execute including workflows_rewst_task_m_365_add_shared_mailbox, workflows_rewst_task_m_365_get_user_licenses_with_friendly_names, workflows_rewst_task_m_365_remove_licenses, workflows_rewst_task_forward_mail, and workflows_rewst_task_exo_set_permissions which use their respective specialized actions for M365 operations.

  7. The workflows_rewst_task_hide_from_gal task uses the Hide From Gal action to manage Global Address List visibility for users across different identity provider configurations.

  8. Communication tasks including workflows_rewst_task_send_message, workflows_function_send_email_with_attachment, and workflows_upload_csv_to_ticket use their respective actions to handle various forms of customer and system communication.

  9. Utility tasks such as workflows_rewst_task_validate_required_fields, workflows_rewst_task_sanitize_input, workflows_rewst_task_convert_guid_to_name, and workflows_rewst_task_resolve_graph_sku_to_offername use specialized actions for data validation, transformation, and lookup operations.

  10. Transform operations including transforms_add_or_subtract_from_date_time, transforms_beta_diff_lists, transforms_filter_list, transforms_get_days_between_dates, and transforms_split_text use their respective transformation actions to manipulate and process data.

  11. Database and query operations are handled by workflows_rewst_task_byod_validate_database_config and workflows_rewst_task_byod_run_query tasks which use specialized database actions for configuration validation and query execution.

  12. PowerShell execution capabilities are provided through workflows_rewst_task_automate_run_powershell which uses the Automate Run Powershell action for remote script execution.

  13. PSA integration is managed through workflows_rewst_process_psa_create_ticket which uses the Process PSA Create Ticket action for ticket creation workflows.

[REWST - TASK] Modify Mailbox Access

  1. The workflow begins with the START task using the noop action, which serves as the entry point and validates the input parameters for the mailbox access modification operation.

  2. The validate_inputs task executes the validation action to verify that all required parameters are present, including the target mailbox identity and the specific permission type to be modified.

  3. The get_mailbox_info task runs the Microsoft Exchange Online InvokeCommand action with the Get-Mailbox cmdlet to retrieve current mailbox information and validate that the target mailbox exists.

  4. The check_permission_type task uses the conditional logic action to determine whether the operation involves adding or removing Full Access permissions, Send As permissions, or both types of access.

  5. The process_full_access task executes the Microsoft Exchange Online InvokeCommand action with the Add-MailboxPermission or Remove-MailboxPermission cmdlet to modify Full Access permissions for the specified users.

  6. The process_send_as task runs the Microsoft Exchange Online InvokeCommand action with the Add-RecipientPermission or Remove-RecipientPermission cmdlet to modify Send As permissions for the designated recipients.

  7. The handle_automapping task uses the Microsoft Exchange Online InvokeCommand action to configure automapping settings based on the shared_mailbox_no_automap parameter when Full Access permissions are granted.

  8. The log_changes task executes the data transformation action to compile a detailed record of all permission modifications, including user identities and permission types that were added or removed.

  9. The update_automation_log task uses the set variable action to publish the standardized automation log containing the operation results and success status for consumption by parent workflows.

  10. The workflow concludes with the END task using the noop action, returning the success status and automation log to indicate completion of the mailbox access modification process.

[REWST - TASK] Sanitize Input

  1. The workflow begins with the START task, which uses the Noop action to initialize the workflow execution.

  2. The workflow proceeds to the sanitize_input task, which also uses the Noop action but contains complex Jinja templating logic to process and sanitize input data.

  3. During the sanitize_input task, the workflow performs a two-pass sanitization process on the input data provided in the list_to_sanitize context variable.

  4. In the first pass, the workflow processes individual fields by iterating through each item in the list and applying specified operations such as trimming whitespace, applying regex patterns for alphanumeric characters, domains, emails, or usernames, and nullifying fields that contain "No Returned" text.

  5. The workflow supports multiple regex operations including regex_alphanumeric for allowing only letters, numbers, and periods, regex_domain for domain names, regex_email for email addresses, and regex_username for usernames.

  6. In the second pass, the workflow handles concatenated fields that may require combining sanitized values from the first pass, such as creating display names from first and last names or user principal names from usernames and email domains.

  7. The sanitize_input task publishes the sanitized output as sanitized_output containing all processed fields and creates a log entry indicating successful completion.

  8. The workflow concludes with the END task, which uses the Noopaction and generates a comprehensive automation log that aggregates all log entries from the workflow execution.

  9. The END task creates a final automation log that includes status codes, success indicators, data summaries, error collections, warning collections, and all individual log entries from the workflow run.

  10. The workflow completes successfully after processing all input sanitization operations and generating the final automation log for tracking and auditing purposes.

[REWST - TASK] Validate Required Fields

  1. The workflow begins with the START task, which uses the Noop action to initialize the workflow execution.

  2. The workflow proceeds to the validate_fields task, which uses the Noop action but contains Jinja templating logic to validate required field data.

  3. During the validate_fields task, the workflow iterates through each field in the list_to_validate context variable to check if required fields are present and contain valid values.

  4. The workflow checks each field to determine if the value is none or an empty string, and if so, adds the field name to a list of missing fields.

  5. For fields that have an expected value specified, the workflow validates that the actual value matches the expected value, and if not, adds the field name along with an error message indicating the incorrect value to the missing fields list.

  6. If no missing or invalid fields are found, the validate_fields task publishes a successful validation result with success: true in the validated_output.

  7. If missing or invalid fields are detected, the validate_fields task publishes a failed validation result with success: false and includes the list of missing or invalid fields in the validated_output.

  8. The validate_fields task creates a log entry indicating that the validation task ran successfully regardless of the validation outcome.

  9. The workflow concludes with the END task, which uses the Noopaction and generates a comprehensive automation log that aggregates all log entries from the workflow execution.

  10. The END task creates a final automation log that includes status codes, success indicators, data summaries, error collections, warning collections, and all individual log entries from the workflow run, providing complete tracking and auditing information for the validation process.

[REWST - TASK] Convert GUID to Name

  1. The workflow begins with the START task, which uses the Noop action to initialize the workflow execution.

  2. The workflow proceeds to the what_to_convert task, which uses the Noop action and contains conditional logic to determine what type of GUID conversion needs to be performed based on the action specified in the guid_to_convert.object.action context variable.

  3. The what_to_convert task evaluates multiple conditions and routes to different conversion tasks based on the action type, including GWS Groups, PSA Contact Location, PSA Child Company, RMM Child Site, User to Copy, User Manager/Supervisor, Forward Mail User, User to Offboard, Delegation Access List, and Transfer Drive To User.

  4. If the action is "gws_groups" and valid ID data exists, the workflow routes to the convert_gws_groups task, which uses the Convert GWS Groups action to resolve Google Workspace group GUIDs to names.

  5. If the action is "psa_contact_location" and valid ID data exists, the workflow routes to the convert_psa_location task, which uses the Convert PSA Location action to resolve PSA location GUIDs to names.

  6. If the action is "psa_child_company" and valid ID data exists, the workflow routes to the convert_psa_child_company task, which uses the Convert PSA Child Company action to resolve PSA company GUIDs to names.

  7. If the action is "rmm_child_site" and valid ID data exists, the workflow routes to the convert_rmm_child_site task, which uses the Convert RMM Child Site action to resolve RMM site GUIDs to names.

  8. For user-related actions including user_to_copy, user_manager, forward_mail_user, user_to_offboard, grant_delegate_access_list, and transfer_drive_to_user, the workflow routes to the convert_gws_usertask, which uses the Convert GWS User action to resolve user GUIDs to names.

  9. Each conversion task publishes detailed log entries with status codes and sub-automation logs, and on success proceeds to the set_output_var task, while on failure proceeds to the action_failuretask.

  10. The set_output_var task uses the Noop action and publishes the converted data as all_converted_items containing the resolved names from the conversion process.

  11. If any conversion task fails, the workflow routes to the action_failuretask, which uses the Noop action to handle failures before proceeding to the end.

  12. The workflow concludes with the END task, which uses the Noopaction and generates a comprehensive automation log that aggregates all log entries, status codes, success indicators, data summaries, error collections, and warning collections from the entire workflow execution.

[REWST - TASK] BYOD: Validate Database Config

  1. The workflow begins with the START task, which uses the Noop action to initialize the workflow execution.

  2. The workflow proceeds to the sql_integration_check task, which uses the Noop action to verify whether the SQL Database integration is installed in the organization.

  3. If the SQL Database integration is installed, the sql_integration_checktask publishes a success log message and continues to the next step, otherwise it sets a failure result indicating the integration is not installed and routes to the failure catch task.

  4. When the integration is confirmed as installed, the workflow moves to the list_db_configurations task, which uses the List Database Configurations action to retrieve all configured database connections.

  5. The list_db_configurations task processes the results and creates a list of all database configuration names, filters for the expected configuration name, and publishes success or failure log entries based on the outcome.

  6. If the database configurations are successfully retrieved, the workflow proceeds to the check_for_config task, which uses the Noop action to validate whether the expected database configuration exists.

  7. The check_for_config task evaluates whether any database configurations match the expected configuration and publishes appropriate results and log entries based on whether the configuration is found.

  8. If the expected database configuration is found, the task publishes a success result stating "Expected Database Config Found" and continues to the end task.

  9. If the expected database configuration is missing, the task publishes a detailed failure result listing the current database configuration names and indicating that the configuration should be "Rewst Cache - Database".

  10. Any failures in the workflow route to the failure_catch task, which uses the Noop action to handle error conditions before proceeding to the end.

  11. The workflow concludes with the END task, which uses the Noopaction and generates a comprehensive automation log that aggregates all log entries, status codes, success indicators, data summaries, error collections, and warning collections from the entire workflow execution.

[REWST - TASK] BYOD: Run Query

  1. The workflow begins with the START task using the noop action, which serves as the entry point and validates the input parameters for the database query operation.

  2. The validate_inputs task executes the validation action to verify that all required parameters are present, including the SQL query string and database connection configuration.

  3. The check_database_connection task runs the SQL Database connection test action to ensure the BYOD integration is properly configured and the database is accessible.

  4. The prepare_query task uses the data transformation action to sanitize and format the SQL query string, ensuring it meets security requirements and proper syntax.

  5. The execute_sql_query task executes the SQL Database execute query action to run the provided SQL statement against the configured database using the established connection.

  6. The process_query_results task runs the data processing action to format and structure the returned database results into a standardized format for consumption by other workflows.

  7. The validate_results task uses the validation action to check that the query executed successfully and returned valid data, handling any potential database errors or empty result sets.

  8. The transform_output task executes the data transformation action to convert the raw database results into the expected output format for integration with Rewst workflows and option generators.

  9. The log_operation task runs the logging action to record the query execution details, including execution time, row count, and any relevant metadata for auditing purposes.

  10. The workflow concludes with the END task using the noop action, returning the formatted query results and success status to indicate completion of the database query operation.

Got an idea for a new Crate? Rewst is constantly adding new Crates to our Crate Marketplace. Submit your idea or upvote existing ideas here in our Canny feedback collector.

PreviousAssign Autotask Configuration Contact Based on Last Logged In User CrateNextBilling Count Report Crate

Last updated

Was this helpful?