Policy Installation

[Saps]

Just assume user A and user B. The user A have made a changes in the policy and just published it without installing the policy. Then user B made another change in the same policy and installed the policy.

Is there any way to restrict the User B to install the policy what are the changes what he have done in Smart 1 Cloud console.

[Tal_Paz-Fridman]

You can implement SmartWorkflow - Approval Cycle for Sessions

https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Cont...

[Saps]

Hi Fridman, Thanks for your reply

We cannot give access for the other admin, but is there any way to restrict the previous changes only published by other admin while installing the policy.

[Bob_Zimmerman]

When you push policy, all published changes are pushed. There is no way to cherry-pick which published changes you want to push. SmartWorkflow does not change this.

What SmartWorkflow can do is add a new step which essentially takes the place of publishing. Admin A would submit their changes. Admin B would submit their changes. These two submitted changes can then be reviewed, and if the review approves them, they are published.

But all published changes go out with the push.

[the_rock]

---

If you want to prevent User B from installing changes they didn’t make

There’s no direct setting that lets you say “install only my changes” in Smart-1 Cloud.
However, you can control this behavior with permissions and workflow changes:

1. Role-Based Permissions

   • In SmartConsole → Manage & Settings → Permissions & Administrators, you can create roles where:

     • Users can publish their own changes.

     • Only specific users (e.g., policy managers) can install policy.

   • That way, User B can’t just install after making changes — only the approved admin can.

2. Workflow with Approval

   • Use the "Install Policy Approval" process:

     • Assign "Policy Installation" to a separate administrator role.

     • Require a change request or peer review before the install is done.

   • This ensures that the installer is aware of all published changes before pushing.

3. Avoid Premature Publishing

   • If User A does not publish right away, their changes remain in their private session, and User B’s install will not include them.

   • Once ready, User A can publish and request an install.

4. Use Revisions for Tracking

   • In Smart-1 Cloud, you can view Revisions in the Logs & Monitor → Audit Logs / Revisions to see exactly what changes were included in a given install.

   • While this doesn’t stop the install, it lets you hold accountability.

[Saps]

Is there any proper document for the configuration of Work flow

[the_rock]

https://sc1.checkpoint.com/documents/Sales_tools/DemoPoint/Quantum_R81.20/Topics/SmartWorkflow.htm